AccessibilitySkip to Top NavigationSkip to Main ContentHome  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

Part 10. Security, Privacy and Assurance

Chapter 8. Information Technology (IT) Security

Section 30. Unisys Operating Systems Security Standards

10.8.30  Unisys Operating Systems Security Standards

10.8.30.1  (09-01-2007)
Purpose

  1. This manual provides security policy and requirements for all Unisys operating systems within the IRS.

10.8.30.1.1  (09-01-2007)
Overview

  1. The Unisys Operating System is used to create and maintain security and resource control on the Unisys Systems. The Site Management Complex (SIMAN) software package and SECMGR software are used to manage this processing. This IRM together with the Unisys Access Standard Profiles Matrix, vendor technical manuals and system documentation developed by appropriate project offices, provide the authorized minimum baseline configuration for IRS Unisys systems. Technical control settings provided in this IRM are primarily based on the capabilities of the Unisys Operating System and SIMAN.

10.8.30.1.2  (09-01-2007)
Scope

  1. The Unisys operating systems security standards apply to all current and future IRS Systems and applications that plan to access and interface with the Unisys Operating Systems.

  2. IRS systems include Tier I systems (Unisys Mainframe Operating Systems).

10.8.30.1.3  (09-01-2007)
IRM Topics

  1. This manual contains information on the following subjects:

    • Authority

    • General Policy

    • Management Controls

    • Operational Controls

    • Technical Controls

    • Deviations

    • Operational System Tag Settings See Exhibit 10.8.30-1.

    • Account Parameter Settings See Exhibit 10.8.30-2.

    • Definitions of Unisys Specific Security Tags See Exhibit 10.8.30-3.

    • Glossary See Exhibit 10.8.30-4.

    • Acronyms See Exhibit 10.8.30-5.

    • References See Exhibit 10.8.30-6.

10.8.30.1.4  (09-01-2007)
Authority

  1. IRM 10.8.1, Information Technology (IT) Security Policy and Guidance, establishes the security program and the policy framework for the IRS.

10.8.30.2  (09-01-2007)
General Policy

  1. The security standards in this IRM apply to all current and future IRS systems and applications that plan to access and interface with the Unisys Operating Systems. This includes, but is not limited to, the Disaster Recovery, Production, MADS, TST and SAT/FIT Unisys environments.

10.8.30.2.1  (09-01-2007)
Roles and Responsibilities

  1. The IRS shall implement security roles in accordance with Federal laws and Information Technology (IT) security guidelines (e.g., Federal Information Security Management Act (FISMA), National Institute of Standards and Technology (NIST), Office of Management and Budget (OMB), Treasury, etc.) that are appropriate for their specific operations and missions.

  2. For further information, see IRM 10.8.2, Information Technology (IT) Security Roles and Responsibilities.

10.8.30.3  (09-01-2007)
Management Controls

  1. Management controls focus on the management of risk for an application or system and the management of computer security controls to mitigate that risk. See IRM 10.8.1 for general information and computer security management control requirements.

10.8.30.4  (09-01-2007)
Operational Controls

  1. Operational controls address security mechanisms that primarily are implemented and executed by people as opposed to systems. They often require technical or specialized expertise and rely on management activities as well as technical controls. See IRM 10.8.1 for general information and computer security operational control requirements.

  2. Additional operational controls specific to Unisys operating system are provided below in the following areas:

    1. Contingency Planning

    2. Configuration Management

    3. Maintenance

  3. Specific operational control procedures applicable to the Unisys system environment are contained in Exhibit 1 of this document. See See Exhibit 10.8.30-1. for additional information.

10.8.30.4.1  (09-01-2007)
Contingency Planning

  1. Information backup procedures and disaster recovery plans shall be documented in accordance with IRM 10.8.1.

  2. Critical data files such as primary and alternate databases shall not be collocated in order to minimize the effects of hardware failures on system integrity and availability.

  3. The system owner shall ensure that the appropriate backup media is stored in a secure off-site facility.

10.8.30.4.2  (09-01-2007)
Configuration Management

  1. The Unisys Operating System and associated products shall have the mechanisms to control access between users and the system resources utilized. File permissions, operating system restrictions, and hardware restrictions are all methods used to limit access to information and resources authorized to users, programs, processes, or other systems.

  2. A top to bottom review and verification of the access controls shall be conducted whenever the operating system is upgraded. The reviewers shall include system/data base programmers, system administrators, the Unisys System Administrator (USA), data base administrators and Mission Assurance and Security Services representatives. At a minimum, the reviewers shall perform the following activities:

    • Identify all access points and resources connected to the system;

    • Determine who shall have access to the system;

    • Document impact of upgrade on Unisys security posture;

    • Develop and update role based profiles and document these decisions in an access matrix;

    • Assign users to profiles that grant access based on "need to know" at the least level of privilege;

    • Determine data set and resource access rules and document these rules in an access matrix.

10.8.30.4.2.1  (09-01-2007)
Configuration Management Systems

  1. All executable code, Executive Control Language (ECL) and scripts used to support tax processing on the Unisys Production systems shall be formally transmitted to the Unisys Production systems through one of the following Configuration Management Systems, the Systems Software Transmittal System controlled by System Support Division (SSD) or the Applications Transmittal System, Software Quality Assurance (SQuA) controlled by the Product Assurance Division Source Code and Documentation Control (SCDC) organization.

  2. All executable code, ECL and scripts used in Systems Acceptability Testing (SAT) on the Unisys SAT/Final Integration Testing (SAT/FIT) systems shall be formally transmitted to those systems through the same two Configuration Management Systems.

10.8.30.4.2.1.1  (09-01-2007)
Applications Software Transmittal System - SQuA

  1. The Applications Software Transmittal System includes all application programs and ECL/scripts that are used to support tax processing. This system is composed of two distinct parts – SQuA and the Production Transmittal Software. SQuA is a Commercial Off the Shelf (COTS) product that is tailored to the IRS environment and resides on the Development System to provide version control, standardized compilation process, and a mechanism for SCDC to control the transmittal of software/scripts to the SAT/FIT system and the Production Transmittal Software. The Production Transmittal Software was created by IRS and resides on the Development System as well as the Production Systems. Applications software and ECL/scripts are processed as batch files on the Development System by SQuA and electronically transferred to the Production systems on a daily (or emergency) basis by the Production Transmittal Software.

  2. Operations staff shall use the Production Transmittal Software on the Production systems to implement the transmittal.

  3. The Applications Software Transmittal System shall be used as follows:

    • Initiation – A Request for Information Services (RIS) or Problem Report (ITAMS ticket or its successor) is received by the applications development staff and work is authorized by IRS management

    • Development – Application programmers use SQuA to create a task, check out source code from the SQuA Production Libraries, compile and map the updated programs and prepare the transmittal memo

    • Transmittal to SCDC – IRS application management uses SQuA to authorize the transfer of changes to the B and C environments

    • Transfer to Production – SCDC staff uses SQuA to accept the task, send the software to the SAT environment for system testing, return the software to application development for corrections, and prepare the transmittal for authorization. SCDC management uses SQuA to authorize the transfer of the software to the Production systems. SCDC staff uses SQuA to save the task components in the SQuA Production Libraries, delete them from the SCDC environment, and transfer the components to the Production Transmittal Software. Enterprise Computing Center Martinsburg, WV (ECC-MTB) Operations staff uses the Production Transmittal Software to transfer the components to the Production systems

    • Implementation – Computing Center Operations staff use the Production Transmittal Software to transfer the components to the Production libraries on the scheduled implementation date

10.8.30.4.2.1.2  (09-01-2007)
Systems Software Transmittal System

  1. The Systems Software Transmittal System include all systems software and utilities on the Unisys Systems and their associated technical documentation. The products necessary to use the system shall be produced and/or maintained by systems programmers in SSD. They include (but are not limited to) COTS code and scripts, IRS specific vendor written code and scripts, shareware, all local code applied to those products, all IRS written utilities and system software control files, and all general purpose scripts and routines.

  2. All products shall have a configuration product identifier that allows version control. The Systems Software Transmittal System shall be used as follows:

    • Change Request Initiation – The Change Request originator or sponsor shall submit the request. A RIS or Problem Report (ITAMS ticket or its successor) may be used to generate the Change Request internally.

    • Change Request Preliminary Evaluation – Management shall make a preliminary assessment of the scope and impact of the Change Request and shall either disapprove, defer, refer or tentatively approve the change.

    • Change Request Detailed Impact Analysis – Technical staff shall perform a detailed analysis to determine both business and technical ramifications of the change request and shall determine the delivery date. Mission Assurance and Security Services shall determine if there are any adverse security ramifications associated with the proposed changes.

    • Change Request Disposition – The appropriate Configuration Control Board shall make the final decision to approve, disapprove or otherwise dispose of the Change Request

    • Change Request Implementation – The organization responsible for implementation shall develop, test, document and transmit changes. Generally, these products shall be piloted on the SAT/FIT system prior to being transmitted to the Production systems. Computing Center Operations staff shall install the transmitted products.

10.8.30.4.2.2  (09-01-2007)
Hardware Environment Requirements

  1. Each of the Unisys partitions or operating environments shall have a different business role.

10.8.30.4.2.2.1  (09-01-2007)
Production Partition or Operating Environment

  1. All production processing shall run on the production partition or operating environment.

  2. No development or testing shall be done in the production environment.

  3. With the exception of changes made by the Computing Center Operations and Support staff to prevent work stoppage, all programs/scripts run on the production systems shall be formally transmitted through the appropriate Configuration Management System.

10.8.30.4.2.2.2  (09-01-2007)
Disaster Recovery Partition or Operating Environment

  1. Disaster recovery partitions or operating environments shall be reserved for production processing in case of a disaster at the main computing center. Disaster recovery tests shall run on these systems at times designated by IRS management while temporary tests shall run at the discretion of the systems administrator.

  2. The environment shall be immediately available for its primary function and no processing or configuration changes that interfere with on going Disaster Recovery processing (e.g. remote mirroring) shall be permitted.

10.8.30.4.2.2.3  (09-01-2007)
SAT/FIT Partition or Operating Environment

  1. Both partitions shall be used for systemic and unit testing of application software and beta testing of systems software. Tax processing shall not run on these partitions.

  2. All programs tested on these partitions shall be transmitted through the appropriate Configuration Management System. The security configuration and processing on these partitions shall match the Production partition as closely as possible.

10.8.30.4.2.2.4  (09-01-2007)
MADS Partition or Operating Environment

  1. All program development and systems software testing shall be performed on this partition.

  2. The MADS partition shall be the alpha site for systems software.

  3. All software used on other systems shall be transmitted from this system through the appropriate Configuration Management System.

10.8.30.4.2.3  (09-01-2007)
Operating System Configuration

  1. Unix shall not be configured on this system.

  2. The security related Operating System Tags shall be set in accordance with See Exhibit 10.8.30-1, Appendix A, in the system configuration at system generation.

  3. Security Option 1 shall be included in the system generation.

10.8.30.4.3  (09-01-2007)
Maintenance

  1. System programmers shall regularly check Unisys operating environment vendor web sites for information on new security patches that are applicable to their environment.

  2. All applicable security patches shall be scheduled and applied to the system in accordance with IT Security Patch Management Policy.

10.8.30.5  (09-01-2007)
Technical Controls

  1. Technical controls focus on the security controls that the computer system executes. These controls provide automated protection from unauthorized access or misuse, facilitate detection of security violations, and support security requirements for the systems or applications. The implementation of technical controls should be consistent with the management of security within the organization. See IRM 10.8.1 for general information and computer security technical control requirements.

  2. Additional technical controls specific to the Unisys Operating System are provided below in the following areas:

    1. Identification and Authentication

    2. Access Control

    3. Audit and Accountability

    4. System and Communications Protection

10.8.30.5.1  (09-01-2007)
Identification and Authentication

  1. The system shall enforce individual accountability by uniquely identifying each user to the system.

  2. Each user shall have only one user-id on the system and that user-id shall be assigned to only one authorized user.

10.8.30.5.1.1  (09-01-2007)
Human User-ids

  1. User-ids in the Unisys security database shall represent an actual person except for system user-ids and specific non-human user-ids authorized by management.

  2. Individual users shall have only one user-id that represents a single person or entity.

  3. User-ids that do not represent individual users shall be limited to those access privileges necessary for system functionality and connectivity and shall require approval and documentation in accordance with these standards and locally developed procedures.

  4. Systems that access applications or other systems protected by Unisys, shall be uniquely identified and shall not be allowed to bypass any Unisys security checks.

  5. The same user id shall be used for each system that the user has access, i.e. PROD, SAT, or FIT.

  6. User-ids shall be 5-12 characters long and composed of the characters A-Z, the numbers 0-9, and the period and hyphen. The characters in the user-id are not case sensitive.

  7. The SEID shall be incorporated into human user-IDs.

10.8.30.5.1.2  (09-01-2007)
System User-ids

  1. System user-ids shall be named and configured for a Controlled Access Protection Environment in accordance with the SSD transmittal and Online Form 5081. These configurations can be found in vendor documentation. The actual profile used shall be at least as restrictive as the vendor recommended configuration.

  2. User-ids not representing an individual shall be limited to the most restrictive access for system functionality. These user-ids shall be approved and documented in accordance with this IRM and locally developed procedures.

  3. The generic batch production user-id shall be named PROD.

10.8.30.5.1.3  (09-01-2007)
Accounts

  1. There shall be one production account in each Access Locator Number (ALN) including the exempt ALN that is used to execute scheduled batch production and support processing. These accounts shall be named XXPROD where XX is the ALN code. The ALN code shall be either the submission center code or 00 for the exempt ALN. Only non- human and system user-ids shall be allowed in these accounts.

  2. The privileged account shall be named 001234. Only users with a documented need to process tape labels shall be allowed access to the privileged account.

  3. All user-ids in an account shall report to the same manager (Exception: the 001234 account). Managers may control multiple accounts and a user-id may be in more than one account. These accounts shall be named XX?????????? where XX is the ALN code and ?????????? shall be 1-10 characters selected by the local site. The only exception shall be the ADS account name which shall not have an ALN code and shall be 1-12 characters.

10.8.30.5.1.4  (09-01-2007)
FIRECALL User-id Management

  1. FIRECALL (emergency) user-ids on Unisys systems shall be established and maintained for emergency or special purposes only. At a minimum, FIRECALL user-ids shall be used for DBA access and Security Administrator access. All other FIRECALL user-ids shall be used in accordance with locally established standard operating procedures that meet the requirements stated in IRM 10.8.1 and this document.

  2. The USA shall be notified no later than the next working day after a FIRECALL user-id has been used. Once the event is over, the USA shall change the password ,place the new password along with the FIRECALL user-id in a sealed envelope and store it in a secure location such as a locked drawer, file cabinet or safe.

  3. When a FIRECALL user-id is used, the individual(s) handling the event shall prepare a report documenting the problem, the solution, and the user involved. A copy of this documentation shall be sent to the local USA on the next business day.

  4. The USA shall audit the activities of the FIRECALL user-id.

  5. See IRM 10.8.1 for additional FIRECALL User-id Management requirements.

10.8.30.5.1.5  (09-01-2007)
Passwords

  1. All password requirements shall be enforced as specified by IRM 10.8.1.

10.8.30.5.2  (09-01-2007)
Access Control

  1. All privileges shall be secured and enforced. Certain privileges shall be available to a user if both the privilege is allowed in the user-id security record and the user has been assigned SYS$*DLOC$.

10.8.30.5.2.1  (09-01-2007)
Interfaces/Executive Requests

  1. The Interfaces/Executive Requests shall be secured and enforced upon system delivery and shall continue to remain in this state (See Unisys Security Administration for ClearPath OS Help 7862-1760 or its successor).

10.8.30.5.2.2  (09-01-2007)
The Access Matrix

  1. The Unisys Access Standards Matrix shall outline the access and privileges authorized for each user role on the system. The matrix represents a baseline of access and privileges.

  2. User-ids and standard access control records (ACRs) shall be profiled in accordance with the Unisys Access Standards Matrix. The matrix shall be maintained and updated by a working group under the leadership of a systems software support or computing center organization selected by IRS management.

  3. Users shall only be granted "explicit access" to the resources based on "least privilege" and "need to know." Other considerations shall come from input from field management, impact on both local staffing, and system performance, compliance with separation of duties, least privilege access, and other business and security guidelines.

  4. Computing centers may be more restrictive in the assignment of Unisys access privileges than described in the matrix. A matrix deviation shall be required if privileges other than those specified in the matrix are requested.

  5. The Unisys security administrator shall determine whether a temporary deviation is legitimate. If a deviation for a special project or other business activity is needed for more than 14 days, but not indefinitely, the working group and the Unisys security administrator shall determine its legitimacy and whether a permanent deviation is required.

  6. All temporary matrix deviations shall be documented. At a minimum, who requested the change, who authorized the temporary deviation, when it was changed when it was changed back, why it was required, and who made the changes shall be required. The Unisys security administrator shall retain all matrix documentation. Adverse system performance impacts caused by the deviation are the responsibility of the site requesting the change. Temporary Matrix deviations that compromise system security are not allowed.

  7. Requests for permanent changes to the access matrix shall also be documented and reviewed by the matrix task group or group responsible for reviewing and approving changes to the matrix (e.g. task group, change control board, etc.). Before permanent updates are made, the requested changes and supporting justification documentation shall be submitted to ACIO, Cybersecurity (formerly Chief, Mission Assurance and Security Service (MA&SS) for review and approval. ACIO, Cybersecurity shall review proposed changes for separation of duties, least privilege access, business need, and compliance with Federal, Treasury, and IRS security guidelines.

10.8.30.5.2.3  (09-01-2007)
Automatic Logon Revocation

  1. The user-id shall be automatically DISABLED by the system after inactivity for the number of days specified in accordance with IRM 10.8.1. The user-id shall not be physically removed from the system at this time.

  2. To be re-activated, users shall be required to submit an authorized Online Form 5081 requesting that their password be reset.

  3. The USA shall manually remove the user-id from all accounts after inactivity for the number of days specified in IRM 10.8.1.

  4. To be reactivated, the user shall be required to submit an Online Form 5081, through their manager, requesting reassignment of the user-id and a new password.


More Internal Revenue Manual