- 1.35.23 Integrated Financial System Security
- 184.108.40.206 Overview
- 220.127.116.11 Background
- 18.104.22.168 Authorities
- 22.214.171.124 Related Resources
- 126.96.36.199 Definitions
- 188.8.131.52 Acronyms
- 184.108.40.206 Responsibilities
- 220.127.116.11.1 Chief Financial Officer and Deputy Chief Financial Officer
- 18.104.22.168.2 Associate Chief Financial Officer for Corporate Planning and Internal Control
- 22.214.171.124.3 Associate Chief Financial Officer for Financial Management
- 126.96.36.199.4 Director, Financial Management Systems Office
- 188.8.131.52.5 Chief, Security and Payroll Section
- 184.108.40.206 Security Administrators
- 220.127.116.11.1 Integrated Financial System - Security Administration
- 18.104.22.168.2 Accessing Integrated Financial System
- 22.214.171.124.3 End User Access
- 126.96.36.199.4 Processing the OL5081
- 188.8.131.52.5 Firecall Procedures for the Integrated Financial System
- 184.108.40.206.6 Role Maintenance
- 220.127.116.11.7 End User Monitoring
- 18.104.22.168.7.1 Audit Procedure Number 1 Ensure Users Have Access to Appropriate Roles
- 22.214.171.124.7.2 Audit Procedure Number 2 Ensure Inactive Users Are Denied Access to the System
- 126.96.36.199.7.3 Audit Procedure Number 3 Mitigate Separation of Duties Risks
- 188.8.131.52.7.4 Audit Procedure Number 4 Maintain Integrity of Security Transactions
- 184.108.40.206.7.5 Security Audit and Analysis System Log Reviews
- 220.127.116.11.7.6 On Line 5081 Reconciliation
- 18.104.22.168.8 Federal Information Security Management Act
Part 1. Organization, Finance, and Management
Chapter 35. Financial Accounting
Section 23. Integrated Financial System Security
June 15, 2017
(1) This transmits new IRM 1.35.23, Financial Accounting, Integrated Financial System Security.
(1) This IRM provides the policies and procedures used by Integrated Financial Systems (IFS) Security.
William H. Maglin II
Associate Chief Financial Officer for Financial Management
This Internal Revenue Manual (IRM) provides the policies and procedures used to ensure there are adequate internal controls in place for the Integrated Financial System (IFS), including its interfaces and sub-systems, in compliance with the Federal Information Security Management Act (FISMA).
The Chief Financial Officer (CFO), Financial Management (FM) Unit, Financial Management Systems Office (FMS), develops and maintains this IRM.
The IFS contains the IRS core administrative financial systems, including expenditure controls, accounts payable, accounts receivable, general ledger and budget formulation. The system also includes a managerial cost accounting capability that enables the IRS to make informed and timely performance-based business and budgetary decisions.
The Office of Management and Budget (OMB) Circular A-130, Appendix III, Security of Federal Automated Information Resources, requires Federal agencies to certify and accredit their information technology systems. This activity also falls within the purview of the FISMA. FISMA consolidates many security requirements and guidance into an overall framework for managing information security and protecting the nation's critical information infrastructure from harm.
The FISMA was enacted in 2002 as Title III of the E-Government Act of 2002, requiring each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source. Annual security reviews of all programs and systems are to be conducted and the results reported to the OMB.
The authorities for this IRM include:
Related resources for this IRM include:
IRM 1.4.3, IRS Guidance for Implementing OMB Circular A-123
IRM 10.8.1, Policy and Guidance
IRM 10.8.8, Sensitive But Unclassified (SBU) Data Policy: Protecting SBU in Non-Production Environments
NIST Special Publication (SP) 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organization
OMB Circular A-123, Management's Responsibility for Internal Control
OMB Circular A-130, Appendix III, Security of Federal Automated Information Resources
In this IRM, the terms below have the following meanings:
Accountability - The traceability of actions performed on an information system to a specific system entity (user, process, and device).
Audit - An independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and procedures, and to recommend necessary changes in controls, policies or procedures.
Audit Trail - A chronological record of system activities that is sufficient to enable the reconstruction, review, and examination of each event in a transaction from inception to output of final results.
Firecall - A method established to provide emergency access to a secure information system in an emergency, time-critical situation. In the event of a critical error or abnormal end, unprivileged users can gain access to key systems to correct the problem.
Identification - The process of verifying the identity of a user, process, or device, usually as a prerequisite for granting access to resources in an information system.
Live Data - Data (e.g., electronic, hardcopy) extracted from taxpayer files which identifies specific individuals or corporate taxpayers and is either sanitized or unsanitized. It includes sensitive information (i.e., SBU), which may include PII.
On-going Authorization (OA) - The subsequent (i.e., follow-on) risk determinations and risk acceptance decisions taken at agreed upon and documented frequencies in accordance with the organization’s mission/business requirements and organizational risk tolerance. An OA is a time-driven or event-driven security authorization process whereby the authorizing official (AO) is provided with the necessary and sufficient information regarding the near real-time security state of the information system (including the effectiveness of the security controls employed within and inherited by the system) to determine whether or not the mission/business risk of continued system operation is acceptable.
Plan of Action and Milestones (POA&M) - A key document identifying specific measures that are planned to correct weaknesses or deficiencies noted in the security controls during the security control assessment; and to address known vulnerabilities in the information system. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones.
Profile - A set of user data that administrators (and sometimes business users) can display and modify. It includes attributes such as name, e-mail address, and language.
Risk - A measure of the extent to which an entity is threatened by a potential circumstance or event and typically a function of the likelihood of: (1) the adverse effects if the circumstance or event occurs and (2) the likelihood of occurrence.
Risk Assessment - The process of identifying, prioritizing, and estimating risks. This includes determining the extent to which adverse circumstances or events could affect an enterprise. Uses the results of threat and vulnerability assessments to identify risk to organizational operations and evaluates those risks in terms of likelihood of occurrence and impacts if they occur. The product of risk assessment is a list of estimated potential impacts and unmitigated vulnerabilities. Risk assessment is part of risk management and is conducted throughout the Risk Management Framework (RMF).
Risk Based Decision (RBD) - A decision made by individuals responsible for ensuring security by utilizing a wide variety of information, analysis, assessment and processes. The type of information taken into account when making a risk-based decision may change based on life cycle phase and decision is made taking entire posture of the system into account. Some examples include: formal and informal risk assessments, risk analysis, assessments, recommended risk mitigation strategies, and business impact. To document risk-based determinations, IT/Cybersecurity has created a Standard Operating Procedure (SOP) and associated Form 14201, Risk Acceptance Request.
Role - A collection of transaction codes and authorization objects used in various business scenarios. Roles are assigned to system users, resulting in authorization profiles that allow them to access and process transactions in the system.
Separation of Duties - A key internal control concept under which no single individual has complete control over a financial transaction from beginning to end.
System Administrator (SA) - An individual employed to maintain and operate the technical aspects of an information system. Usually charged with supporting and maintaining computer systems, and planning for and responding to service outages and other problems. SAs also monitor and maintain the SAP Roles in IFS.
User Account - An operating system data object containing information identifying a user to an operating system. A user account typically contains a user’s name and password, group memberships, and rights and permissions for accessing an information system and its resources.
The following chart contains acronyms used throughout this IRM.
ACRONYM DESCRIPTION AO Authorizing Official AQETL Automated Quarterly Excise Tax Listing ASCA Annual Security Control Assessment ATO Authorization To Operate BU Business Unit BW Business Warehouse CAMS CFO ARDI Management System CASTS Custodial Audit Support Tracking System CFO Chief Financial Officer CPO Certification Program Office DAA Designating Approving Authority DR Defect Resolution ECC ERP Central Component eCM Enterprise Continuous Monitoring ELC Enterprise Life Cycle ERB Engineering Review Board FIPS Federal Information Processing Standards FISMA Federal Information Security Management Act FM Financial Management FMC ESC Financial and Management Controls Executive Steering Committee FMIS Financial Management Information System GAO Government Accountability Office GRAS Government Relocation and Accounting System IFS Integrated Financial System IRM Internal Revenue Manual ISCM Information Security Continuous Monitoring ISCP Information System Contingency Plan IT Information Technology LD Live Data LDW Live Data Waiver NIST National Institute of Standards and Technology OL5081 On Line 5081 PGLD Privacy, Governmental Liaison and Disclosure PIA Privacy Impact Assessment PII Personally Identifiable Information PMO Project Management Office POA&M Plan of Action and Milestones (POA&M) POC Point of Contact RBD Risk-Based Decision RRACS Redesign Revenue Accounting Control System SA System Administrator SAAS Security Audit and Analysis System SAR Security Assessment Report SBU Sensitive But Unclassified SME Subject Matter Expert SMR Structured Management Review SNC Secure Network Communications SOP Standard Operating Procedure SP Special Publication TFIMS Treasury FISMA Inventory Management System TIGTA Treasury Inspector General for Tax Administration
This section provides responsibilities for the:
Chief Financial Officer and Deputy Chief Financial Officer
Associate Chief Financial Officer for Corporate Planning and Internal Control
Associate Chief Financial Officer for Financial Management
Director, Financial Management Systems Office
Chief, Security and Payroll Section
The Chief Financial Officer (CFO) and Deputy Chief are responsible for overseeing the OMB A-123 Circular (A-123) responsibilities in support of Treasury’s assurance statement and ensuring IRS controls over financial reporting are properly identified, tested and evaluated.
The Associate Chief Financial Officer (ACFO) for Corporate Planning and Internal Control (CPIC), Office of Internal Control (CPIC-IC) is responsible for:
Ensuring A-123 assessment objectives are clearly communicated throughout the agency.
Developing the assessment methodology.
Coordinating activities and time-lines with Treasury and Government Accounting Office (GAO).
Enhancing review to meet Structured Management Review (SMR) requirements (where applicable).
Providing oversight and assistance to ensure assessment is carried out in a thorough, effective and timely manner.
Administering the Governance process to include: chairing the A-123 Review Board and providing scheduling and administrative support, presenting status and results of A-123 activities to the Financial and Management Controls Executive Steering Committee (FMC ESC) and the A-123 Review Board, and documenting key decisions.
Communicating with agency management and employees regarding the assessment.
Identifying Subject Matter Experts (SMEs) to develop complete and timely test plans.
Communicating and coordinating with external oversight groups.
Serving as central repository for all official A-123 records.
The ACFO for Financial Management (FM) owns the IFS System and is responsible for:
Ensuring compliance with the CFO Act, FASAB, Treasury, OMB, Federal Financial System Requirements, and other financial requirements.
Managing the IRS financial management system operations and monitoring financial systems for compliance with accounting standards and internal controls.
Identifying the requirements and the best approach for upgrading, enhancing, and/or modifying the IRS financial system to meet ongoing financial management requirements.
Providing financial system modernization development support and ensuring system integrity.
Analyzing business processes and best practices to identify potential areas for operational improvement.
Monitoring performance indicators for timeliness and accuracy.
The Director, Financial Management Systems Office, is responsible for:
Supporting IFS operations and maintenance activities.
Ensuring the quality of systems enhancements.
Managing and prioritizing the processing of IFS change requests, defect resolution requests, and service requests.
Providing support to troubleshoot technical and performance issues related to administrative financial systems.
Providing support for the annual GAO financial statement audit.
Providing support for special reporting requirements, audit extracts, OMB Circular A-123, Management's Responsibility for Internal Control, and documentation and testing for payroll.
Ensuring new technologies are incorporated to improve the quality and delivery of financial systems.
Managing security profiles and ensuring FISMA compliance.
Managing the IFS Help Desk.
The Chief, Security and Payroll Section, is responsible for:
Managing the IFS security profiles.
Maintaining Help Desk statistics for all Knowledge, Incident/Problem, Service and Asset Management (KISAM) tickets for IFS, performing quarterly reviews on Help Desk Tickets, and reviewing ticket problem categories to assess types of errors reported and to identify trends.
Issuing IFS Alert messages for system availability/shutdown, etc.
Coordinating the on-going authorizations of IFS.
Identifying and participating in critical IFS disaster recovery application activities.
Providing user support to business units, as well as other CFO organizations.
The IFS administrators are CFO employees assigned to the Financial Management Systems Office, Security and Payroll Section.
Security has two main functions:
Manage all IFS security administration activities.
Manage all activities needed to meet annual requirements of the FISMA.
The IFS contains the IRS core administrative financial systems, including expenditure controls, accounts payable, accounts receivable, general ledger and budget formulation.
The IFS SAs ensure Business Unit (BU) users are assigned to the proper role(s).
The IFS users must submit an OL5081 to request and obtain IFS access.
The IFS SAs will manage all IFS administration activities, including:
Approving and denying access to IFS, establishing user accounts and profiles, and assigning IFS roles.
Monitoring IFS user access.
Establishing IFS Security policies and procedures.
Enforcing IFS Security policies and procedures.
The IFS is accessed by use of a single sign-on using Secure Network Communications (SNC).
The IFS Security utilizes the OL5081 system to process requests for system access. Users are required to obtain access to IFS through the OL5081.
Each IFS role is displayed in the OL5081 in a drop-down menu of applications available for selection.
If multiple BUs have access to an IFS role, the role is listed in the OL5081 as a separate line item selection for each BU. For any IFS role request, IFS Security Coordinators in each BU approve OL5081 requests for users in that BU before the request continues along the approval path to CFO Security for processing. Some IFS BW roles are restricted. Requests for these roles must first be approved by an SME on the BW Team in CFO Operations before access is granted by CFO Security. The SME is on the approval path following BU Security Coordinator approval and before CFO SA approval. For non-restricted BW roles, BW SME approval is bypassed on the approval path and requests flow from (b) to (d) as detailed below.
The approval chain for approving an OL5081 request is as follows:
BU Security Coordinator
CFO IFS Business Warehouse SME - For ‘Restricted’ BW Roles Only
CFO IFS Security Administrator
Each IFS role has a role owner. The role owner is a SME in that particular BU function.
The IFS SAs use their judgment and expertise on evaluating the role requests and determining whether to approve or deny a request. They will consult the user, the user’s manager, or the role owner as required.
As a general rule, IFS contractors should not be given access to the IFS Production environment with the exception of temporary access, which is granted under the IRS/IFS Firecall process.
A limited number of production support staff contractors will continue to have production access to support critical activity (for example, IFS month-end close processing and BW Load Validation and Reconciliation processing).
The IFS SAs process the OL5081.
The IFS SAs will determine which IFS system environment the user is requesting access to. Below is a list of the IFS system environments:
Environments ERP Central Component (ECC) Business Warehouse (BW) Production
RP1 (ECC production)
BP1 (BW production)
RT1 (ECC test)
RT1 Snap (ECC test)
RT2 (ECC test)
RT2 Snap (ECC test)
RT3 (ECC test)
RT4 (ECC test)
BT1 (BW test)
BT2 (BW test)
The IFS SA will determine if the OL5081 record is an ‘ADD’ or ‘DELETE’ to ensure correct processing in IFS.
The IFS SA will then approve the record in the OL5081 after assigning the role to the user in IFS. If the user’s IFS role request is improper or invalid, the request will be denied in the OL5081 and the user is notified of the denial by the OL5081 system.
If the OL5081 record is for an IFS/IT contractor requesting access to IFS production, the request must first be approved by the IT Project Manager for the contract, along with CFO Management.
The IFS SA will forward an email to the IT Project Manager and CFO Management for approval.
Firecall procedures, which are system-specific, shall be implemented for use only in emergency situations when elevated access is required.
The use of Firecall procedures will be documented to include the reason for use and the expected time-frame for the use. More information can be found in IT IRM 10.8.1.4.1.1.6, Fire Call Account and theFirecall Access Standard Operating Procedure.
Contractors with developer access should not have access to the IFS production environment. Firecall access should only be granted for a limited period and IFS role assignment should be based on the security principle of least privilege. These IRS IT firecall procedures provide IFS production access to IFS functional teams when needed to support development and Defect Report (DR) processing.
The IFS/IT contractors will obtain approval from CFO Management and Contractor Management for firecall access.
The IFS/IT contractors will provide auditable documentation of the firecall approval and monitoring.
The IFS/IT contractors will record the activities performed in production during the firecall access period.
Upon firecall approval, IFS Security will assign the requested roles for the requested duration of time.
The IFS roles assigned to the IFS/IT contractor will automatically expire at 12:00am following the ‘Valid To’ day/date specified in the firecall request.
The IFS SA will sign the firecall approval form after granting access and will return the signed firecall form to the IFS/IT contractor coordinating the firecall request.
If the firecall task cannot be completed within the approved time-frame, a firecall extension request can be made and granted.
The extension request for firecall access must be approved by IFS/IT contractor management.
Role maintenance is periodically performed in IFS to manage user roles and profiles, and to update authorization data based on selected menu functions.
IFS user roles, which are based on business unit and job-title, are the basis of the Profile Generator function. Roles are the connection between the user and corresponding authorizations, which ultimately allow users to successfully process IFS transactions in the system.
An integral part of the role maintenance activity is change management. Formal change-management procedures are required when roles are changed to add or remove transactions and field values, or when new roles are created in IFS to reflect business changes.
The following criteria will be used when determining if/when changes to an IFS role should be presented to the Engineering Review Board (ERB) for review and approval:
Current transaction authority is removed from a role (not duplications)
Role changes impacting 100 or more users
Privacy Act information added to a role
The following criteria will be used by the role owner, when presenting authorization and role maintenance activities to the ERB:
Review requested role changes and activities with the SME.
Develop the role change in the RT1 (test environment) system.
Open a Defect Report (DR) and promote the proposed change to the production stage area in Clearquest.
Test the role change for any potential issues.
Prepare the ERB form to document the change being requested and include all supporting attachments and documentation.
Upload the approved ERB form and attach it to the associated DR in Clearquest. This places the role change on the ERB meeting agenda for discussion and approval.
After approval, the role change moves through Clearquest along the systems development life-cycle to production.
Documentation for role maintenance activities is maintained in Clearquest and through the recordation of meeting minutes at each scheduled ERB.
End user monitoring and its frequency are an integral part of IFS Security’s standard procedures. They include:
Daily processing of OL5081 requests to add/remove user access (Audit Procedure Number 1).
Biweekly review to lock inactive user accounts (Audit Procedure Number 2).
Monthly review of critical IFS role combinations to mitigate separation of duty risks (Audit Procedure Number 3).
Quarterly review of IFS SA access to mitigate separation of duty risks (Audit Procedure Number 4).
Weekly review and analysis of IFS SAAS Log data from IT/Cybersecurity.
On a monthly basis, IFS user access and OL5081 user authority is reconciled.
The IFS Security audit procedure #1 ensures that IFS users have the correct and most appropriate access in order to perform their assigned duties.
OL5081 requests for IFS access are reviewed and processed daily.
All users requiring access to IFS must first submit their request for access in the OL5081 before any role permissions are granted in their IFS SAP user profile. All OL5081 requests requiring action/processing by FM/CFO Security include:
ADD - User requests to add an IFS role to an IFS SAP profile.
DELETE - User requests to delete (remove) an IFS role from an IFS SAP profile.
Once the OL5081 is approved by the employee’s manager, the request is routed electronically and it follows an established approval chain process distinguished by BU and IFS role. The approval chain process for IFS role requests/approvals is:
Employee Management Approval
BU/IFS Security Coordinator Approval
CFO SA Approval
Additional approvals may be required and incorporated into the approval chain for roles that provide access to Personally Identifiable Information (PII) data.
Prior to approving an OL5081 and granting access to a role, the IFS SA uses various checks to verify roles and their appropriateness for the user. While failing to meet any of the checks will not necessarily mean disapproval of an OL5081, it may require further investigation on the part of the IFS SA to determine the appropriateness of the role for the user. This investigation may include:
BU check – prior to approving an OL5081, the IFS SA should verify that the requested role is for the correct BU. As a general rule, OL5081s should only be approved when the OL5081 matches the BU of the user. The user’s BU can be verified by checking the Discovery Directory, or by checking the address book on Outlook.
In cases where an OL5081 has never been created for the BU under the role requested, then the IFS SA will need to determine if there is a legitimate business need for the role prior to approving the OL5081.
Job assignment check – this check involves checking the OL5081 role request against the user’s job assignment.
Segregation of duties check – before granting access to a role, the IFS SA should check the user’s existing roles to determine if the new role assignment will cause any segregation of duties issues. If a role would cause a segregation of duties issue, then either the exiting role should be expired before the new role is approved, or the new role should be denied. Examples of role assignments that create a segregation of duties issue include the following:
• Accounts Payable and Accounts Receivable roles
• Accounts Payable and Approver roles
As a general rule, IFS IT contractors should not be given access to IFS ECC production. However, temporary access may be authorized under the firecall process.
OL5081 requests received by IFS SAs should have already been approved through the approval chain. The IFS SA is the last one to approve or deny an OL5081 request.
All users will complete an Annual Recertification in the OL5081 system. Please see OL5081 Employee Guide.
IFS Security audit procedure #2 ensures that inactive IFS users are denied access to the system.
IFS user accounts are disabled (locked) after 45 days of inactivity and quarantined (deactivated) after 180 days of inactivity in both ECC and BW. This denial of access is an automated process, which executes every second Tuesday.
The system will perform an online review using transactional query ‘SUIM’ to disable the accounts of users who have not logged into IFS within a 45-day period and quarantine users who have not logged into IFS within a 180-day period.
If the account has been disabled, the user must submit a KISAM ticket indicating that their account has been locked. The KISAM ticket is processed through the IFS Help Desk and an email is sent to IFS Security to unlock the user. Once unlocked, the user will have two (2) weeks to log into their account(s) or they will be locked again due to inactivity.
If an account has been quarantined, the user will need to submit new OL5081 requests for any roles they require; thereby, reactivating the quarantined account.
IFS Security Audit procedure #3 ensures appropriate separation of duty and promotes the principle of least privilege for a majority of IFS users.
The purpose of the critical combination analysis is to determine segregation of duties, roles, and transactions in IFS.
The IFS SA will perform this analysis monthly.
The Critical Combination Report provides a current snapshot of user roles, transactions, and permissions in the system. The report is run against a standard set of combined critical transaction scenarios, and it highlights and captures all user profiles with multiple or stacked roles matching the critical combination scenarios.
Although many transactions and roles are critical in IFS, along with user profiles assigned to them, the focus of the report analysis is primarily targeted to users in the [IRS-END_USER] User Group. These users are considered IFS general users who should not have elevated access or a critical combination of roles/transactions in the system. Any exceptions to this guideline require further analysis and management concurrence to justify the business need for the critical combination.
All other IFS user groups, as defined in the system, are permitted to maintain this critical or elevated access at this time.
IFS Security Audit procedure #4 ensures that the integrity of key IFS Security profile transactions are maintained in the system.
On a quarterly basis, a security administrator will perform an online review of security transactions by processing transactional queries against the following functions:
Role Maintenance (PFCG)
User Information System (SUIM)
User Maintenance (SU01)
Lock Transactions (SM01)
The IFS accounting system collects and records weekly security audit log information. This data is captured and forwarded to the Security Audit Analysis System (SAAS) interface by IT/Cybersecurity. IT/Cybersecurity then collects this data generates reports in Excel format based on the raw data transmitted by IFS through the SAAS interface.
The Excel reports are based on selected critical transaction codes and other event criteria mutually agreed to by IT/Cybersecurity and CFO.
The Excel reports are sent to CFO-Security by IT/Cybersecurity for review and analysis. The reports include:
Failed Logon Report – This report generates a list of system failed login attempts.
Critical Transaction Codes Report – This report generates a list of critical transactions based on a list of transaction codes provided to IT/Cybersecurity.
Unusual Logon Times Report – This report generates a list of system logins and logouts to capture SEIDs of users logging in during non-working hours.
IT/Cybersecurity sends these reports weekly and the security administrators review a statistical sample.
Security administrators rotate this assignment on a monthly basis.
The weekly reports cover a seven-day period (from Tuesday through Monday) and IT/Cybersecurity forwards these reports to CFO Security by email on Wednesday or Thursday, at the latest.
If it is not received by Wednesday afternoon, the IFS SA assigned for that month will notify IT/Cybersecurity.
If the report still has not been received by the following Tuesday, the IFS SA will escalate this to the Chief, Security and Payroll Section, for resolution.
The OL5081 reconciliation process is used to synchronize IFS user access with current OL5081 authorizations.
When a mismatch is found, an analysis must be done by the IFS SA to determine the best corrective action to take.
The reconciliation is performed once a month.
The FISMA requires agency program officials, CIOs, and inspector generals to report the results to OMB. This data is used by OMB to assist in its oversight responsibilities and to prepare the annual report to Congress on agency compliance with FISMA, which requires the head of each agency to implement policies and procedures to cost-effectively reduce information technology security risks to an acceptable level.
The information and supporting evidence needed for security accreditation is developed during a detailed security review of an information system, typically referred to as security certification. Security certification is a comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security accreditation, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. The results of a security certification are used to reassess the risks and update the system security plan, thus providing the factual basis for an AO to render a security accreditation decision.
A major component of the security certification and accreditation process for the system is the System Security Plan (SSP). During the security certification and accreditation process, the SSP is analyzed by IT FISMA Compliance Team, updated, and accepted. The certification agent confirms that the security controls described in the SSP are consistent with the Federal Information Processing Standards (FIPS) 199 security category determined for the information system, and that the threat and vulnerability identification and initial risk determination are identified and documented in the SSP, risk assessment, or equivalent document.
The objectives of enterprise Continuous Monitoring (eCM) are to assess security controls against their intended effectiveness, provide updated security information to designated organizational officials who can take appropriate risk mitigation actions and make credible authorization decisions regarding the operation of the information system, and foster a more robust Plan of Action and Milestones (POA&M) update and reconciliation process.
On-going Authorizations utilize security tools to automate aspects of system security monitoring. IT/Cybersecurity will perform annual security controls assessments (ASCA) to document security controls and functions are in place, and operating as intended. The AO will acknowledge risk via signature on the ASCA Security Assessment Report (SAR). The AO will acknowledge the transition to Information Security Continuous Monitoring (ISCM) via an updated Authorization to Operate (ATO) memo.
The On-going Authorizations is being enforced for the following:
ISCM is based on law - Title III, Public Law 107-347, commonly known as ‘Federal Information Security Management Act (FISMA) of 2002’, mandates assessing the risk and magnitude of the harm that could result from the unauthorized access, use, disclosure, disruption, modification, or destruction of such information and information systems.
FIPS PUB 199 mandates Standards for Security Categorization of Federal Information and Information Systems. National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Revision 4, FIPS 200 mandates Minimum Security Requirements for Federal Information and Information Systems operating under an on-going authorization.
Cybersecurity is evaluating 'Risk-Based Control Selection':
• Likelihood - Measure of how often a control may change (volatility) and probability of failure or compromise overtime.
• Impact - Effect of control failure or non-implementation.
• Control Risk = Likelihood X Impact.
The CFO Security Team is the Point-Of-Contact (POC) for the CFO Systems and is responsible for:
Collecting and submitting all evidence for the selected controls to IT/Cybersecurity.
Creating POAMs when findings occur.
An Information System Contingency Plan (ISCP) provides procedures and capabilities for recovering an information system. An ISCP details the steps that need to be taken in order to resume normal operations of the information system following a disruption in service.
The IFS ISCP consists of three phases:
Activation/Notification Phase: Activation of the ISCP occurs after a disruption or outage and at the discretion of the appropriate executive-level management. Notification of stakeholders, recovery teams, and users occurs upon activation.
Recovery Phase: The Recovery phase details the activities and procedures for recovery of the disrupted system.
Reconstitution Phase: The Reconstitution phase defines the actions taken to test and validate system capability and functionality at the original or new permanent location as part of a return to normal operations. This phase consists of two major activities: validating successful recovery and deactivation of the plan.
The ISCPs can be found in Treasury FISMA Inventory Management System (TFIMS).
The Security Team is the POC for the ISCP and is responsible for:
Making all updates to the ISCP.
Distributing the updated ISCP to the appropriate individuals.
The Privacy Impact Assessment (PIA) is the documentation of the analysis by system owners to reduce risks to personal information. The eGov Act requires PIAs to be performed during design and development so privacy protection is built in. The FISMA Certification Program Office recommends that the project office engage the Privacy, Governmental Liaison and Disclosure (PGLD) early in the Enterprise Life Cycle (ELC).
The Security Team is responsible for updating the PIA.
A POA&M is a requirement for managing the security weaknesses pertaining to a specific application or system. In addition to noting weaknesses, each POA&M details steps that need to be taken to correct or mitigate any weaknesses, as well as resources required to accomplish task milestones and a correction/mitigation timeline.
A POA&M is intended to help identify, assess, and prioritize security weaknesses, and monitor progress on appropriate corrective actions. In order to meet FISMA requirements, agencies like the IRS must maintain POA&Ms in TFIMS for each system in their inventory.
The POA&M development follows an eight-step process:
Identify the weakness.
Identify/assign a responsible POC.
Prioritize the weakness.
Develop remediation strategy.
Record POA&M weakness information into TFIMS.
Take corrective action to resolve/mitigate the weakness.
Monitor/update the POA&M.
Report to Treasury and OMB.
A Risk-Based Decision (RBD) is the result of an analysis of risk to organizational operations (including mission, function, image, or reputation), organizational assets, individuals, other organizations, and the Nation; and a determination that a requirement can be met (or not met) only with an RBD to an IRS IT security policy, requirement, or standard.
IRS policy (NIST SP 800-53, Privacy Controls for Federal Informations Systems and Organizations, and IRM 10.8.1, Policy and Guidance) allows Designated Approving Authorities (DAAs) to tailor security control baselines for their systems using a cost-effective, risk-based approach. This type of risk-based decision-making gives DAAs a process by which they can make exceptions or deviations to IRS IT security policies based on credible justification and a thorough assessment of the risks incurred as a result of the deviation.
According to IRM 10.8.1, Information Technology (IT) Security, Policy and Guidance, the reasons for a DAA to consider a deviation are:
Meeting the requirement is technically not possible.
Meeting the requirement is cost-prohibitive; and
Meeting the requirement is operationally not feasible and would cause an undue burden to the system and/or seriously hinder its capability to accomplish its mission.
Deviation requests must be documented on Form 14201, and are required for any situation in which the system will be operating outside of IRS IT security policy, whether related to a technical, operational, or management control. Risk-based decision or deviation weaknesses are maintained as ongoing POA&M weaknesses.