Retaining Financial and Business Management System (FBMS) Access

TABLE OF CONTENTS

OVERVIEW

4.1 What is the purpose of this chapter? This chapter describes:

A. The U.S. Fish and Wildlife Service’s (Service) requirements for employees to continue to retain access to key subsystems within the Financial and Business Management System (FBMS). FBMS is the financial system of record for the Department of the Interior (Department); and

B. The information technology security requirements that drive the policy in the chapter.

4.2 What is the scope of this chapter? This chapter applies to all Service accounts in key subsystems in FBMS (see section 4.3 for more information). For cross-servicing users (i.e., users who perform work in FBMS for more than one bureau), this chapter only applies to their Service FBMS account.

4.3 What do you need to know about FBMS to understand access requirements?

A. Subsystems. There are two types of subsystems in FBMS. For the purposes of this policy, we call the two types of subsystems “key” and “non-key.” The subsystems are connected to each other within the FBMS security boundary. See Table 4-1.

Table 4-1: Types of Subsystems in FBMS

(1) The Service does not have the authority to remove access to non-key subsystems without coordination/assistance from other entities.

(2) The Service may unilaterally remove access to key subsystems.

B. Roles. Staff use many roles (e.g., ACQ_REQ (i.e., Acquisitions Requisitioner), AP_DCM (i.e., Accounts Payable Document Content Manager), CC_BFR (i.e., Charge Card Budget Officer)) to access FBMS.

(1) One role may access multiple subsystems.

(2) The Service may assignan FBMS user multiple roles or one role to access a subsystem.

C. Factors for access. For a user to access FBMS and make changes to data, the user must have all of the following:

(1) Access to the Department’s internal network,

(2) An active, unlocked Active Directory account (typically this means the user must have an active Personal Identity Verification (PIV) card),

(3) An active FBMS user ID with roles assigned to it, and

(4) An unlocked FBMS user status.

4.4 What is the overall policy?

A. The Department controls the various access requirements for each non-key subsystem and works with the Joint Administrative Operations (JAO), Administrative Operations Center (AOC) Financial Systems/FBMS Operations, User Support team to identify and resolve user access issues to those systems. The Department controls the automatic locking of accounts or subsystems. FBMS automatically locks out users after 45 days of no activity in FBMS. Some subsystems automatically lock out users after 45 days of inactivity for that subsystem, even though the user is active in other subsystems.

B. Users must log on to and use each key subsystem for which they need access at least once every 365 days. Users do not have to use every role they are assigned within that 365 days, but they must use at least one of their roles to enter the key subsystem to retain their access. (See section 4.8 for more information about why these security requirements are in place.)

(1) FBMS users who have not accessed any key subsystem in FBMS for the previous 365 days will be locked out of that subsystem. We will remove all of their roles and their User Identification (ID) from all key subsystems when possible.

     (a) If the user has no remaining roles in FBMS, we will deactivate them. Deactivation removes all roles that can enter information into FBMS.

     (b) If a user receives an automated report(s) from EMIS at least once every 365 days, we consider them active users in EMIS.

     (c) We cannot deactivate or remove some roles from users immediately because of workflow requirements (e.g., we cannot remove Contracting Officers if they have an open contract because the invoice payments on the open contract will fail). When a role cannot be removed, the FBMS user ID must be locked. After all of the workflow items that depend on the user ID are complete, we will remove the role(s). We will deactivate the user if appropriate.

(2) FBMS users who access and use one key subsystem, but not another, for the previous 365 days, will retain access to the subsystem used and lose access to the unused key subsystem(s). We will remove access to the unused key subsystem(s) and will remove roles when possible.

(3) FBMS users who access and use one key subsystem within the past 45 days, but have not accessed another key subsystem, will retain access to the key subsystem used and may be automatically locked out of the unused key subsystem(s). If they are locked out, all of their roles remain intact, but they must submit a request to the FBMS Help Desk to be unlocked in the unused subsystem.

4.5 What are the authorities for this chapter?

A. Departmental Security Control Standard, Access Control, Version 4.1, September 2016 or the latest version as it is implemented by the Department.

B. Federal Information Security Modernization Act of 2014 (FISMA) (44 U.S.C 3553).

C. National Institute of Standards and Technology (NIST) Special Publication 800-53 Rev. 4; Security and Privacy Controls for Federal Information Systems and Organizations; April 2013 and updated January 22, 2015 or the latest version of NIST SP 800-53 as it is implemented by the Department.

D. Office of Management and Budget (OMB) Circular A-123, Management’s Responsibility for Internal Control.

E. OMB Circular A-130, Revised, Transmittal Memorandum No. 4, Management of Federal Information Resources.

4.6 What terms do you need to know to understand this chapter?

A. Business Integration Office (BIO) is an office within the Department that supports the integration of new or modified systems that focus on those business functions within the Department that report to the Deputy Assistant Secretary for Budget, Finance, Grants, and Acquisition.

B. FBMS is the official financial management system of the Department. It is an SAP-based, off-the-shelf enterprise resource planning system. FBMS integrates the Department’s financial management functions into a single system. FBMS supports business management processes related to financial management, budget execution, acquisition, grants and cooperative agreements, real and personal property management, fleet management, aviation, travel, enterprise information management, and reporting.

C. FBMS4ALL is a role within FBMS that gives all Departmental Federal employees access to the FBMS Tableau server, UPerform, and the Intra-Departmental Agreement (IDA) process.

D. FBMS Account Controllers are Service personnel who approve security/access procedures for an assigned area within FBMS. They are responsible for reviewing and approving role assignments and revocations of users within their areas of accountability. To remove roles from a user in FBMS, the FBMS Account Controller and the Security Point of Contact (SPOC) must approve it.

E. FBMS inactivity occurs when a user has not performed an action in any of the FBMS key subsystems (e.g., running a report in EMIS, entering financial data into Core Financials). Logging into the FBMS portal, but not using any of the subsystems, does not prove activity. Users have to use the subsystem. Users who schedule reports regularly in EMIS and have them automatically emailed remain active.

F. FBMS portal is also known as the FBMS frontend. It provides access or links to subsystems within FBMS depending on a user’s approved roles. The portal does not contain transactional or financial data, but may include user guides, training materials, and general information about the system.

G. FBMS security personnel, include, but are not limited to:

(1) FBMS Account Controllers, and

(2) FBMS Training Coordinators.

H. SAP is a commercial software product that, as of the date of this policy, the Department has licensed to use as part of FBMS. SAP software performs several functions within FBMS, including, but not limited to, performing finance functions.

I. SPOCs support the management and administration of users in FBMS by monitoring, approving, and removing users and user role assignments. FBMS SPOCs interact frequently with the BIO security team and the FBMS security teams from other bureaus and offices.

RESPONSIBILITIES

4.7 Who is responsible for the elements of the Service’s FBMS access policy? See Table 4-2.

Table 4-2: Responsibilities Related to the FBMS Access Policy

REQUIREMENTS

4.8 What Departmental information technology security requirements drive the policy in this chapter?

A. The Department requires that we monitor and control all information technology/system user accounts. The Departmental Security Control Standard, Access Control requires us to:

(1) Identify and select the types of information system accounts we need to support organizational missions/business functions (i.e., individual, group, system, application, guest/anonymous, and temporary);

(2) Assign account managers for information system accounts;

(3) Establish conditions for group and role membership;

(4) Specify authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;

(5) Require approvals from account managers for requests to create information system accounts;

(6) Create, enable, modify, disable, and remove information system accounts in accordance with the procedures or conditions the system owner defines;

(7) Monitor the use of information system accounts;

(8) Notify account managers, which for FBMS is the Financial Systems/FBMS Operations, User Support team, when:

     (a) Accounts are no longer required,

     (b) Users separate or are terminated or transferred, and

     (c) Individual information system use or need-to-know changes;

(9) Authorize access to information systems based on:

     (a) A valid access authorization,

     (b) Intended system use, and

     (c) Other attributes that the organization or associated missions/business functions require;

(10) Review accounts for compliance with account management requirements at least annually; and

(11) Establish a process for reissuing shared/group account credentials when we remove individuals from the group.

B. In addition to monitoring and controlling accounts, the Department requires that we grant only the amount of access that users need to perform their jobs. We should assign users only the roles that they need to complete their work assignments.

4.9 What does the Department recommend as the best practice for system inactivity? The guidance from the Department’s Office of the Chief Information Officer (OCIO) recommends that for a financial system such as FBMS, it is a best practice for users to have their roles removed and their ID deactivated in the system after the user has not used the system for between 180 and 365 days.

4.10 How often is FBMS access and use monitored? Following BIO policy and guidance, the Service’s FBMS User Support team performs a comprehensive user review at least annually. In addition to the BIO-mandated reviews, the Service’s FBMS User Support team performs a partial user review monthly to help with continuous monitoring. If the Department or BIO updates its policy or guidance to require reviews more frequently, the Service’s FBMS User Support team will adhere to the more frequent review requirements.

4.11 What are some examples for which an employee’s access may be removed? See Table 4-3.

Table 4-3: “If-Then” Scenarios for Deactivation

4.12 Can the Service grant an exception to this policy? Yes, the Financial Systems/FBMS Operations Branch Chief, User Support, Financial Systems may grant exceptions to this policy on a case-by-case basis. To request an exception, please contact the Financial Systems/FBMS User Support team.