Controls Over the Masterfile System Are Generally Adequate,
But Some Improvement Is Needed
June 2001
Report Number:
2001-20-092
This report has cleared the Treasury
Inspector General for Tax Administration disclosure review process and
information determined to be restricted from public release has been redacted
from this document.
June
18, 2001
MEMORANDUM
FOR Deputy Commissioner for
ModernizatioN/Chief
Information Officer
FROM: Pamela J. Gardiner
/s/ Pamela J. Gardiner
Deputy
Inspector General for Audit
SUBJECT: Final Audit Report -
Controls Over the Masterfile System Are Generally Adequate, But Some
Improvement Is Needed
This report
presents the results of our review of the controls over the Internal Revenue
Service’s (IRS) Masterfile computing system.
In summary, we found the security-sensitive system components and
settings on the operating system of the Masterfile system to be adequate. However, there are several areas where
improvements are needed to maintain a necessary level of security for the
Masterfile system.
We recommended
that the Chief, Information Technology Services, and the designated offices
ensure that security documentation is current and complete, correct the
identified non-compliant access controls, ensure that key system libraries are
closely monitored and reviewed, and strengthen system password controls. Management agreed with our recommendations
and developed appropriate corrective actions.
Management’s comments have been incorporated into the report where
appropriate, and the full text of their comments is included as Appendix V.
Copies of this
report are also being sent to the IRS managers who are affected by the report
recommendations. Please contact me at
(202) 622-6510 if you have questions or Scott E. Wilson, Associate Inspector
General for Audit (Information Systems Programs), at (202) 622-8510.
Security Documentation for the Masterfile Mainframe System Is Incomplete and Outdated
System Password Format Should Be Modified to Enhance User Authentication
Appendix I – Additional Information on Weaknesses Identified
Appendix II – Detailed Objective, Scope, and Methodology
Appendix III – Major Contributors to This Report
Appendix IV – Report Distribution List
Appendix V – Management’s Response to the Draft Report
The Masterfile
computers are integral to the mission of the IRS and its collection activities.
This report presents the results of our review of the system software and system access controls of the Internal Revenue Service’s (IRS) Masterfile mainframe computers residing at the Martinsburg Computing Center (MCC). The Masterfile computers are integral to the mission of the IRS and its collection activities by hosting the following systems:
§ Masterfile: The IRS’ database that stores various types of taxpayer account information. This database includes individual, business, and employee plans and exempt organizations data.
§ Corporate Files On-Line (CFOL): CFOL provides nationwide access to information processed through any district/service center and posted to any of the Masterfiles.
§ Information Returns Processing: Nationwide, all information returns, such as Forms 1099, are sent to the MCC where an extensive Information Returns Masterfile is maintained.
Due to its importance
to the IRS and the nation, the IRS must pay careful attention that the
Masterfile system complies with Federal Government and IRS prescribed policies
and procedures.
The Masterfile is a unique system in its importance to the
IRS and the economy of the
In general, we found the security-sensitive system components and settings for the Masterfile operating system[1] to be adequate. However, we identified weaknesses with the security documentation, systems software management, and several logical access controls, that require management’s attention to ensure the security of the Masterfile mainframe system. The identified conditions indicate that the Masterfile mainframe system is potentially vulnerable to unauthorized access and, as a result, sensitive data maintained on the system could be improperly used, changed, or destroyed.
The overall objective
of this review was to evaluate the system software and system access controls
of the Masterfile mainframe computers.
The overall objective of this review was to evaluate the system software and system access controls of the Masterfile mainframe computers and assess the IRS’ progress in meeting appropriate security requirements for these mainframes.
During this review we determined whether:
§ Controls over Masterfile computer system resources provided reasonable assurance that data files, application programs, and computer-based facilities and equipment were protected against unauthorized modification, disclosure, loss, or impairment.
§ Controls over access to and modification of Masterfile computer system software provided reasonable assurance that operating system-based controls are not vulnerable to intentional or accidental changes.
§ Pertinent security documents were completed and effective security procedures were implemented.
The Treasury Inspector General for Tax Administration (TIGTA) controlled this review and received assistance from the Information Technology staff of the General Accounting Office (GAO) in completing the technical aspects of this review. This assistance included the use of the GAO’s computer lab to perform some of our audit tests.
To assist in our review of controls over the access to and modification of the computer system software on the Masterfile system, we used Computer Associate’s audit software, CA-Examine. CA-Examine helps identify control and security exposures in OS/390 operating systems. We used this product to analyze the controls governing critical operating system programs and settings.
This review addresses the IRS’ strategy of promoting effective asset and information stewardship by evaluating the system-level security of the Masterfile system. This strategy includes several security-related goals, including the review of the state of IRS security and a focus on providing solutions to identified weaknesses.
Audit work was performed on-site at the MCC and in the IRS’ National Headquarters in the offices of the Chief, Information Technology Services, from July 2000 to March 2001. This audit was performed in accordance with Government Auditing Standards.
Detailed information on findings identified in this report and specific recommendations are presented in Appendix I. Details of our audit objective, scope, and methodology are presented in Appendix II. Major contributors to this report are listed in Appendix III.
In
general, we found the controls over sensitive system components and settings
for the Masterfile operating system to be adequate.
In general, we found the controls over sensitive system components and settings for the Masterfile operating system to be adequate. Our review of the system software components found that the settings for the high-risk components[2] are generally appropriate. In addition, our review of logical access controls found that adequate controls are in place to identify and authenticate users, restrict access to appropriate programs and information, and monitor and review audit trails of user activity.
There are several areas, however, where improvements are needed to maintain a necessary level of security for the Masterfile system. Such improvements are needed because any control weaknesses found on the Masterfile system, even minor ones, are amplified due to the importance of this system to the Federal Government and the nation’s economy.
Security Documentation for the Masterfile Mainframe System Is
Incomplete and Outdated
The foundation for ensuring adequate protection
for this, or any system, is adequate security documentation.
In a system that is as essential to the nation’s tax processing capability as the Masterfile system, it is of utmost importance that it be adequately protected from all preventable security breaches. The foundation for ensuring adequate protection for this, or any system, is adequate security documentation. Without adequate documentation, security controls may be inadequate and/or inconsistently applied. Such conditions may lead to insufficient protection of sensitive or critical resources and data.
Our review identified several security policies in place for the Masterfile. Specifically:
§ A Computer Security Plan for the Masterfile system.
§ A Risk Analysis of the Masterfile system.
§ An IRS-wide Law Enforcement Manual (LEM) specifying security standards for OS/390 systems.
§ Several MCC security policies to supplement the above policies.
Our review of the security documentation for the Masterfile system identified that several of the documents do not meet the minimum standards set forth in Federal and IRS guidelines, including the Office of Management and Budget’s (OMB) Circular A-130, “Management of Federal Information Resources,” the Internal Revenue Manual (IRM), and the recently released Federal Information Technology Security Assessment Framework. Specifically, both the Computer Security Plan and Risk Analysis were completed in 1995. OMB Circular A-130 and IRS guidelines require these documents to be updated at least every 3 years. Consequently, they do not reflect changes to the system or its environment, including upgrades in the mainframe hardware and changes in the location of personnel supporting the Masterfile system. In addition, while the Computer Security Plan includes all of the section titles required by OMB Circular A-130 and the IRM, the necessary detailed information as prescribed by these standards was not included.
For example, the Computer Security Plan is
required by Circular A-130 to include personnel controls regarding initial and
periodic screening of individuals “authorized to bypass significant technical
and operational security controls of the system commensurate with the risk and
magnitude of harm they could cause.” On
the Masterfile system, such authorization includes users granted system-level
privileges. However, the Computer Security
Plan does not include this requirement.
Consequently, only 5 of the 11 users with this level of access had
background investigations completed in the last 5 years, with only 1 user
having an investigation completed in the last 3 years. The remaining users were last screened
between 10 and 25 years ago. By not
conducting periodic background investigations on users with system-level
privileges, the IRS runs the risk of failing to detect continuing unauthorized
employee actions by individuals with sensitive access to one of the most
important information systems in the IRS.
Without
current and complete security documentation, the IRS cannot ensure that all
risks and vulnerabilities to its computer systems have been identified,
assessed, and adequately mitigated.
These documents form the foundation of the
security program for the Masterfile system, which includes the implementation,
administration, and oversight of security for the system. If the information contained in these
documents is not current and complete, the security program for the Masterfile
system may not have the information needed to adequately secure the
system. As a result, the IRS cannot
ensure that all risks and vulnerabilities to its computer systems have been
identified, assessed, and adequately mitigated.
We were informed by MCC personnel that they had completed the required revisions to the documentation and were waiting further action from the Certification Office. In our communications with the Office of Security Evaluation and Oversight (SEO), we were unable to obtain a current schedule for updating the Masterfile security documentation. In addition, we were unable to determine why a significant amount of time had passed since this documentation was last updated.
System-Level Access Controls Are Generally Adequate; However, Several Controls Are Not in Compliance with Internal Revenue Service Policies
Access controls should provide reasonable assurance that a computer system and its application programs and data are protected against unauthorized modification and disclosure. Inadequate access controls diminish the reliability of computerized data and increase the risk of unauthorized modification, disclosure, loss, or impairment of data. On the Masterfile system, logical access controls are implemented through the Resource Access Control Facility (RACF). The IRS has established standards for the use of the RACF through the RACF LEM. These standards must be followed diligently in order to maintain a strong control environment that prevents unauthorized access and compromise of the system.
Our
review of logical access controls found that, in general, adequate controls are
in place to identify and authenticate users, restrict access to appropriate
programs and information, and monitor and review audit trails of user activity.
Our review of logical access
controls found that, in general, adequate controls are in place to identify and
authenticate users, restrict access to appropriate programs and information,
and monitor and review audit trails of user activity. However, several instances were identified
where controls on the Masterfile system were not in compliance with controls
specified in the RACF LEM. Specifically,
we identified instances where controls were
non-compliant for assigning sensitive privileges to users and groups of users,
timely removal of unnecessary access, and implementing the system-level
auditing facility for two system resources.
The
MCC staff advised us that some of the instances identified above deviated from
the LEM requirements because of periodic peaks in their workload, which caused
the MCC staff to postpone all but crucial processes. For other instances, the MCC staff believes
that the deviations are necessary so that the users can perform their assigned
responsibilities. However, waivers for
deviations from the LEM had not been submitted for approval to the SEO, as
required by the LEM. In addition, the
lack of a security review in the year 2000 contributed in part to
non-compliance with the controls. In the
past, the SEO has conducted such reviews; however, none were conducted at the
MCC during the year 2000.
The MCC staff disagrees with the LEM requirement ***(b)(2), (b)(7)(E)***. In their view, implementing such a requirement would generate an excessive amount of unnecessary system audit trail records. To support their position, the MCC technical staff cited IBM documentation which states that, as a general rule, ***(b)(2), (b)(7)(E)***. The SEO, however, has informed us that they do not plan to remove this requirement from the LEM. Although we believe a waiver should be submitted, we were unable to obtain sufficient information to determine from a technical viewpoint whether it should be granted.
System Software Controls Are Generally Adequate; However, Several Key System Libraries Need to Be More Proactively Managed
With
two exceptions, our review found the settings for the high-risk components of
the system software to be generally appropriate.
System software is a set of programs designed to operate and control the processing activities of computer equipment. Programs on OS/390 operating systems are organized into libraries, through which access to the programs is controlled. Controls over access to and modification of system software are essential in providing reasonable assurance that operating system-based security controls are not compromised and that the system will not be impaired. Inadequate controls in this area could lead to unauthorized access and circumvention of security controls to read, modify, or delete critical or sensitive information and programs. In our assessment of the controls over the system software configuration on the Masterfile system, we found the settings for the high-risk components of the system software to be generally appropriate, with two exceptions. In addition, we identified 49 users with privileged access to many key system libraries and determined that, based on their job responsibilities, this access is appropriate.
The exceptions identified were weaknesses in several key system libraries. Specifically, we found the following:
§ There are weaknesses with two key system libraries that, in the absence of compensating controls, would present a significant security risk to the system by creating the opportunity for an unauthorized program to gain privileged access to the system. For these libraries, there are compensating controls in place to prevent this situation from occurring. However, it is possible that, in the future, other system software libraries might be vulnerable if compensating controls are not in place.
§ There are programs with identical names that exist within numerous key system libraries. Our review of all 172 key system libraries identified 101 libraries that contained instances of identically named programs. IBM documentation explains that the existence of programs with the same name could lead to the accidental or deliberate use of the wrong programs and the possible introduction of a system integrity exposure.
These two weaknesses resulted from the lack of specific policies or guidance on managing the content of these key system libraries. The IRM does not include policies or guidance on maintaining system software for the Masterfile system. However, the IRM assigns the responsibility for developing overall Masterfile processing procedures to the MCC. While the MCC has local procedures in place for managing the installation and configuration of system software, there are no specific procedures in place for managing the contents of these key libraries. The documentation accompanying the CA-Examine tool recommends that authorized key system libraries should be closely monitored for frequency of updates due to the powerful access granted to these libraries.
System Password Format Should Be Modified to Enhance User
Authentication
User access to information systems is typically controlled through identification and authentication of the user. Identification is the process of distinguishing one user from all others, usually through the use of user identifiers (UserID). Authentication is the process for determining whether users are who they say they are. The most widely used method of authentication is through the use of passwords. Passwords can be structured at varying levels of complexity to increase the level of difficulty in compromising passwords and user authenticity.
Our
review of password controls on the Masterfile system determined that the
password settings for the system appear adequate; however, the password format
can be improved.
Our review of the password controls on the Masterfile system determined that the password settings for the system appear adequate and compliant with IRS and Federal Government requirements for password length. Although the password length is technically in compliance with these requirements, it has been given a structure that limits the protection offered by a password of its length. For example, the password format for the Masterfile system does not prevent users from creating passwords that closely mirror the format of their UserID or including easily guessed user information (e.g., meaningful dates). In addition, the Masterfile system password format makes it easier for passwords not to conform to IRM password standards, such as requirements not to use obvious combinations of letters and numbers or personal information in user passwords. The password format also results in significantly fewer possible password combinations (6.7 million) than the format required for other similar mainframe systems at the MCC (119 million). Consequently, this format could allow an internal attacker to more easily guess an authorized system user’s password. Once the attacker obtains a user’s password, he or she can then execute all the system commands that are ascribed to that user.
We also found that the password format for the Masterfile mainframe system, as well as other MCC mainframes, is posted on the MCC Intranet website. This website is accessible to all IRS employees and authorized contractors. The IRM, while not specifically prohibiting this situation, does require that a system should block out any demonstration of password length. While passwords are in fact blocked out on the Masterfile system, the existence of the password structure on the Intranet site circumvents this control by making the password length available not only to users of the Masterfile system but anyone with access to the IRS Intranet.
The specific recommendations for this report are presented in Appendix I. In summary, to correct the weaknesses identified in the report, the Chief, Information Technology Services and the designated offices should:
§ Ensure that security documentation for the Masterfile system is current and complete, including specific requirements for background investigations of users with sensitive system access.
§ Correct the identified non-compliant access controls or obtain approval to waive LEM requirements, and coordinate periodic reviews of the Masterfile system to ensure access controls are compliant with the LEM.
§ Ensure that authorized key system libraries are closely monitored by systems programmers and reviewed to prevent duplication of programs in these libraries.
§ Remove system password formats from the MCC Intranet and increase the complexity of the password format on the Masterfile system.
Management’s Response: IRS management stated that the Masterfile security documentation is now complete, except for the Security, Test and Evaluation test plan. IRS management also stated that steps have been taken or are in process to correct the non-compliant access controls. In certain instances, waivers for the LEM requirements are being developed. Programs are being developed to notify programming personnel of duplicate key system library programs. IRS management has removed the system password formats from the Intranet and will study increasing the complexity of system passwords.
Management’s complete response has been included as Appendix V to this report.
The Masterfile system
is critically important to the nation’s ability to collect taxes and therefore
must remain at the highest levels of security.
The IRS’ Masterfile system is one of the most important systems in the IRS and is critically important to the nation’s ability to collect taxes. Consequently, the system must be adequately secured and in compliance with appropriate Federal and agency guidelines to prevent the opportunity for minor weaknesses to escalate into system compromises.
Appendix I
Additional Information on Weaknesses Identified
The Masterfile mainframe system is integral to the mission of the Internal Revenue Service (IRS) and the focal point of the nation’s tax processing capability. In 1999, the IRS collected $1.9 trillion in taxes, processed 130 million tax returns from individuals and businesses, and recorded 234 million payments. These numbers are projected to grow throughout the foreseeable future. In addition, at the time of our review there were over 1,300 users with system-level access to the Masterfile system, which includes users such as programmers, operators, and database administrators. Of these, 14 users had been granted system-level attributes, or privileged levels of access to the system, which enables these users to either issue all security commands, access protected resources, or modify audit settings. Any control weaknesses found on the system, even minor ones, are amplified due to the importance of this system to the Federal Government and the nation’s economy.
Security Documentation for
the Masterfile Mainframe System Is Incomplete and Outdated
In a system that is as essential to the nation’s tax processing capability as the Masterfile system, it is of utmost importance that it be adequately protected from all preventable security breaches. The foundation for ensuring adequate protection for this, or any system, is adequate security documentation. Without adequate documentation, security controls may be inadequate and/or inconsistently applied. Such conditions may lead to insufficient protection of sensitive or critical resources and data.
Our review identified several security policies in place for the Masterfile, including:
§ A Computer Security Plan for the Masterfile system.
§ A Risk Analysis of the Masterfile system.
§ An IRS-wide Law Enforcement Manual (LEM) specifying security standards for OS/390 systems.[3]
§ Several Martinsburg Computing Center (MCC) security policies to supplement the above policies.
Our review of the security documentation for the Masterfile system identified that several of the documents do not meet the minimum standards set forth in Federal and IRS guidelines. Specifically, the following standards apply:
§ In November 2000, the Chief Information Officers Council released a new framework for managing risks to computer systems. This framework provides the Federal Government a consistent approach in conducting annual program reviews required by the Government Information Security Reform Act. To meet the minimum requirements of the first level of the new framework, the computer system must have “a formally, up-to-date documented policy that establishes a continuing cycle of assessing risk, implements effective security policies including training, and uses monitoring for program effectiveness.”
§
Office of
Management and Budget (OMB) Circular A-130, “Management of Federal Information
Resources,” states that security controls in each system should be reviewed
“when significant modifications are made to the system, but at least every 3
years. The scope and frequency of the
review should be commensurate with the acceptable level of risk for the
system.”
§
The IRS’
Internal Revenue Manual (IRM) states “The security plan must be reviewed annually.” If such a review is not completed, the system
could become vulnerable to significant unidentified risks that place the
integrity of the system in question.
We found that two important security documents did not meet these standards as a result of being significantly out of date and missing some required information. Specifically:
§
Computer
Security Plan: Our review of the security documentation for
the Masterfile system determined that the Computer Security Plan for the system
was completed in mid-to-late 1995. (An
approximation of the date was necessary since the Computer Security Plan was
not dated.) While the Computer Security
Plan includes all of the headings found in OMB Circular A-130, the IRM, and
National Institute of Standards and Technology requirements, the information
under each heading does not meet the requirements prescribed by the
standards. These headings address system
identification, system function and purpose, sensitivity of information handled
by the system, status of security activities and control measures, rules of
behavior, training, personnel controls, incident response capability,
continuity of support, technical security, and system interconnection.
§
Risk
Analysis: The Risk Analysis of the Masterfile system,
dated September 1995, was completed to fulfill the requirements of OMB Circular
A-130 and the requirements for System Security Certification. The Masterfile system was certified in
November 1996. Our review of the Risk
Analysis identified that several areas of the document are out-of-date and do
not reflect significant changes made to the system since it was certified. For example, at the time of the Risk
Analysis, the Masterfile system was hosted on two
Without current and complete security
documentation, the IRS cannot ensure that all risks and vulnerabilities to its
computer systems have been identified and adequately mitigated. For example, the Computer Security Plan is
required by Circular A-130 to include personnel controls regarding initial and
periodic screening of individuals “authorized to bypass significant technical
and operational security controls of the system commensurate with the risk and
magnitude of harm they could cause.” On
the Masterfile system, such authorization includes users granted system-level
attributes (system-SPECIAL, etc.).
However, the Computer Security Plan does not include this
requirement. Consequently, only 5 of the
11 users with this level of access had background investigations completed in
the last 5 years, with only 1 user having an investigation completed in the
last 3 years. The remaining users were
last screened between 10 and 25 years ago.
By not conducting periodic background investigations on sensitive system
users, the IRS runs the risk of failing to detect improper employee actions by
individuals with sensitive access to one of the most important information
systems in the IRS.
We were informed by MCC
personnel that they had completed the required revisions to the documentation
and were waiting further action from the Certification Office. In our communications with the Office of
Security Evaluation and Oversight (SEO), we requested a current schedule for updating
the Masterfile security documentation and the reason for the delay, but none
was provided.
1. The Chief, Information Technology Services, should ensure the security documentation for the Masterfile mainframe system is reviewed and made current and complete, according to existing Federal standards.
Management’s Response: All security re-certification documentation is complete for the Masterfile mainframe system. The final step in the process is the completion of the Security, Test and Evaluation test plan.
2. The Chief, Information Technology Services, should ensure that the Computer Security Plan for the Masterfile system includes specific requirements for periodic background investigations of individuals with sensitive system access of no less than every 5 years. These individuals should include, at a minimum, users with system-level attributes.
Management’s Response: A management team composed of representatives from the MCC, the SEO, and Personnel Security will re-evaluate the Computer Security Plan and associated investigative requirements for sensitive system access.
System-Level Access Controls Are Generally Adequate; However, Several Controls Are Not in Compliance with Internal Revenue Service Policies
Access controls should provide reasonable assurance that a computer system and its application programs and data are protected against unauthorized modification and disclosure. Inadequate access controls diminish the reliability of computerized data and increase the risk of destruction or inappropriate disclosure of data. The scope of our review included an assessment of logical access controls, or controls implemented through computer hardware and software to prevent unauthorized access to a system.
On the Masterfile system, logical access controls are implemented through the Resource Access Control Facility (RACF). Our review of logical access controls found that, in general, adequate controls are in place to identify and authenticate users, restrict access to appropriate programs and information, and monitor and review audit trails of user activity.
The IRS’ RACF LEM
establishes a set of standards that will create and maintain a strong access
control environment for systems using the RACF.
These standards must be followed diligently in order to maintain a strong
control environment that prevents unauthorized access and compromise of the
system.
Our review of the
logical access controls for the Masterfile system identified several instances
where controls were not in compliance with the RACF LEM. Specifically:
§ ***(b)(2), (b)(7)(E)***
§ ***(b)(2), (b)(7)(E)***
§ ***(b)(2), (b)(7)(E)***
§ ***(b)(2), (b)(7)(E)***
§ ***(b)(2), (b)(7)(E)***
§ ***(b)(2), (b)(7)(E)***
Through discussions with
MCC Security staff, it was acknowledged that for some of the instances
identified above the staff does not follow the LEM requirements because of
periodic peaks in their workload, which caused the MCC staff to postpone all
but crucial processes. For other instances,
the MCC staff believes that the deviations are necessary in order for the users
to perform their assigned responsibilities.
However, waivers for deviations from the LEM had not been submitted for
approval to the SEO, as required by the LEM.
In addition, the lack of
a security review of the Masterfile system during 2000 contributed in part to
the identified non-compliant controls.
In the past, the SEO has conducted periodic security reviews, usually
twice a year, at IRS facilities. These
reviews included testing of both physical and logical controls over systems at
IRS facilities.
***(b)(2),
(b)(7)(E)***create an unnecessary burden. To support their position, the MCC technical
staff cited the IBM RACF Security Auditor’s Guide, which states that as a
general rule accesses to most general resources should not be audited. The SEO, however, has informed us that they
do not plan to remove this requirement from the LEM. During the review we were unable to obtain
sufficient information to determine whether a waiver of this requirement is
warranted.
3.
The
Director, MCC, should correct the identified instances of non-compliance with
the LEM on the Masterfile system or obtain approval to deviate from the LEM
from the SEO.
Management’s Response:
·
Over the
past several years, the MCC has taken steps to considerably reduce the number
of staff having multiple group-level attributes.
·
The System
Auditor attribute was removed from the Security Specialist’s UserID after
completion of the assigned tasks.
·
The unique
nature of the work periodically necessitates deviating from the LEM. Whenever this occurs, the MCC Security and
Disclosure Branch will prepare and submit a deviation request from the RACF LEM
standard. The deviation request will
include a justification for the deviation, including the steps to be
taken to mitigate risks.
·
The MCC
Security and Disclosure Branch will schedule and monitor regular reviews of
UserIDs that are ***(b)(2),
(b)(7)(E)*** in order to delete them from the
system. The reviews will support proper
system maintenance and assist in ensuring the system complies with the
LEM.
·
***(b)(2),
(b)(7)(E)*** performance
problem arises as the result of this capability being activated, the MCC
Security and Disclosure Branch will prepare and submit a deviation request from
the RACF LEM standard.
·
The Director,
MCC, reviewed applicable system definitions and determined that all data are
now current.
4. ***(b)(2), (b)(7)(E)***
Management’s Response: The MCC
Security and Disclosure Branch will prepare and submit a deviation request from
the RACF LEM standard. The request will
include a justification for the deviation, including the steps to be taken to
mitigate risks.
5.
***(b)(2),
(b)(7)(E)*** in compliance with the IRS’ RACF LEM.
Management’s Response: An
onsite review of the MCC and the Masterfile system was performed by the SEO
during the week of April 23 through April 27, 2001. In addition, SEO analysts are gaining remote
access to the Masterfile to conduct periodic, unannounced online reviews of the
Masterfile system to ensure that its access controls are in compliance with the
RACF LEM and other requirements. These
reviews will be separate from the onsite reviews
***(b)(2), (b)(7)(E)*** in compliance with the RACF LEM.
System Software Controls Are Generally Adequate; However, Several Key System Libraries Need to Be More Proactively Managed
System software is a set of programs designed to operate and control the processing activities of computer equipment. Programs on OS/390 operating systems are organized into libraries, through which access to the programs is controlled. Controls over access to and modification of system software are essential in providing reasonable assurance that operating system-based security controls are not compromised and that the system will not be impaired. Inadequate controls in this area could lead to unauthorized access and circumvention of security controls to read, modify, or delete critical or sensitive information and programs.
In our assessment of the controls over the system software configuration on the Masterfile system, we found the settings for the high-risk components,[6] including system exits, supervisor calls, and input/output appendages, are generally appropriate. In addition, we identified 49 users with privileged access, including UPDATE or ALTER access, to Authorized Program Facility (APF) libraries. We determined that, based on their job responsibilities, this access is appropriate. However, our review identified two weaknesses with the APF libraries that, in the absence of compensating controls, would present a significant security risk to the system.
Specifically, our review of the APF-authorized libraries identified two libraries that were not located on the volume specified in the APF list. Such a discrepancy is identified by the system when booted, or initial program load (IPL), but not necessarily brought to the attention of appropriate personnel. In the absence of compensating controls, this would present a significant security risk by creating the opportunity for an unauthorized program to become APF authorized by using the same name and volume specified on the APF list. As a result, it would be possible for such a program to circumvent all standard OS/390 security controls, including access to secured data. Our review of the Masterfile system identified compensating controls, through RACF profiles for these libraries, to prevent this situation from occurring. However, it is possible that other system software libraries in the future might be left vulnerable if, for instance, the profiles governing these libraries are less restrictive and permit widespread access to modify the libraries.
We also found that identically named programs exist within APF libraries. IBM guidelines state that installations using APF authorization must control which programs are stored in authorized libraries and ensure that no two programs with the same name exist across the set of authorized libraries. However, we found that 101 of all 172 APF libraries reviewed contained instances of identically-named programs. Collectively, over 18,000 instances of duplication exist 2 or more times within these 101 APF-authorized libraries. The existence of programs with the same name could lead to the accidental or deliberate use of the wrong programs and the possible introduction of a system integrity exposure.
These two weaknesses resulted from the lack of specific policies or guidance on managing the content of these key system libraries. Our review of the IRM did not identify any policy or guidance on maintaining system software or the APF list. However, the IRM assigns responsibility for developing overall Masterfile processing procedures to the MCC. While the MCC has local procedures in place for managing the installation and configuration of system software, there are no specific procedures in place for managing the contents of the APF list or members of APF libraries. The documentation accompanying the CA-Examine tool recommends that APF libraries be closely monitored for frequency of updates due to the powerful access granted to these libraries.
Recommendations
6. The Director, MCC, should ensure that the APF libraries are closely monitored, including devising a control mechanism to alert systems programmers at IPL of APF-authorized libraries that are not on volumes specified in the APF list.
Management’s Response: The MCC will write a utility program that will read the Progxx members of Parmlib and report any discrepancies. This will be a ControlM job that will execute at least once a week. Notification of any discrepancies will be sent to various systems programmers and managers.
7. The Director, MCC, should develop procedures for periodically reviewing the contents of APF libraries to ensure that instances of duplicate programs are reduced.
Management’s Response: The MCC implemented procedures for a system monitoring program to periodically produce a report of the duplicate modules. This report is being reviewed to ensure there are no unnecessary duplication of modules.
System Password Format
Should Be Modified to Enhance User Authentication
User access to information systems is typically controlled through identification and authentication of the user. Identification is the process of distinguishing one user from all others, usually through the use of UserIDs. Authentication is the process for determining whether users are who they say they are. The most widely used method of authentication is through the use of passwords. Passwords can be structured at varying levels of complexity to increase the level of difficulty in compromising passwords and user authenticity.
Our review of the password controls on the Masterfile system determined that the password settings for the system appear adequate. The parameters for revocation of inactive passwords and mandatory password changes are appropriate. In addition, the password length is in compliance with IRS and Federal Government requirements.
Although the password length is technically in compliance with these requirements, it has been given a structure that limits the protection offered by a password of its length. As a result, the password format for the Masterfile system is not sufficiently complex and could allow an internal attacker to more easily guess an authorized system user’s password. Once the attacker obtains a user’s password, he or she can then execute all the system commands that are ascribed to that user.
Specifically, the password format on the Masterfile system is “AANNNN,” where A is an alpha character and N is a numeric character. This format is problematic for the following reasons:
· The format too closely mirrors the format of the UserIDs. Therefore, users may likely use the UserID in the password.
· The format lends itself to easily guessed passwords, such as user initials and birthdate, last four digits of the user’s social security number (SSN), or some other significant number.
Other IRS mainframe computers running the OS/390 operating system and using the RACF have more complex password formats. For example, the ICS/ACS/PRINT (Integrated Collection System/Automated Collection System/Printer Replacement to Integrate New Tools) system, another OS/390-based mainframe system at the MCC, uses a password format comprised of mostly alpha characters. However, one numeric character is used and is placed in the middle of the password. For the Masterfile system, such a structure would increase password complexity by preventing users from mirroring their UserID as well as using meaningful dates. Such a format would also increase the number of possible password combinations from 6.7 million to 119 million passwords, significantly decreasing the likelihood of password compromise.
In addition, the Masterfile system password format makes it easier for passwords to not conform with standards specified in the IRM:
· Passwords should not be comprised of obvious combination of letters and numbers (e.g., first names, last names, initials, birth dates, or user identifications spelled backwards).
· Passwords should not be created that are related to personal identity, history, or environment.
· The system shall provide a means for ensuring the complexity of user-entered passwords.
In addition, the required password format for the Masterfile mainframe system is posted on the MCC Intranet website. This website is accessible to all IRS employees and authorized contractors. The IRM, while not specifically prohibiting this situation, does require that a system should block out any demonstration of password length. While passwords are in fact blocked out on the Masterfile system, the existence of the password structure on the Intranet site circumvents this control by making the password length available not only to users of the Masterfile system but anyone with access to the IRS Intranet.
Recommendations
8. The Director, MCC, should ensure that system password formats are removed from the MCC Intranet.
Management’s Response: System password formats were removed from the Intranet.
9. The Director, MCC, should restructure the password format for the Masterfile system to increase the complexity of the passwords, thus making them more difficult to guess or crack.
Management’s Response: A management team led by the SEO, and assisted by the MCC, will assess the adequacy of existing passwords and conduct a feasibility study for restructuring password formats.
Appendix II
The overall objective of
this review was to evaluate the system software and system access controls in
the Masterfile system and assess the Internal Revenue Service’s (IRS) progress
in meeting appropriate security requirements for this system. This review included evaluation of the
general control environments over the production Masterfile mainframe systems
at the
To accomplish these objectives, we:
I. Obtained background information on the Masterfile system to determine how critical the system is to the IRS’ tax processing system by:
A. Reviewing system manuals and other documentation to gain an understanding of the system.
B. Identifying the number of users with access to applications residing on the Masterfile mainframe as well as with direct access to the system.
C. Identifying the volume of transactions and the dollar amount being processed by the Masterfile mainframes on an annual basis.
D. Identifying the number of systems that can request database extracts or other information from the system.
II. Assessed the Masterfile system security policies to ensure a risk assessment policy was in place and effective security procedures had been implemented by:
A. Researching current topics in the areas of mainframe and network security, including recent security breaches and corresponding solutions to identify potential risk areas.
B. Determining if a current risk assessment exists for the Masterfile and reviewing it to ensure that vulnerabilities were identified and mitigated.
C.
Determining if a current security plan for the
Masterfile existed and reviewing it to ensure it covered all major components
and included topics prescribed by the Office of Management and Budget’s
Circular A-130, including:
· Rules of the system/Application rules.
· Training/Specialized training.
· Personnel controls/Personnel security.
· Incident response capability.
· Continuity of support/Contingency planning.
· Technical security/Technical controls.
· System interconnection/Information sharing.
III. Determined whether controls over access to and modification of system software provided reasonable assurance that operating system-based controls were not compromised and that the system would not be impaired by:
A. Determining that all access paths through the system software had been identified and controls implemented to prevent or detect access for all paths. Specifically, we:
1. Obtained a list of vendor-supplied software and determined if any of these products had known deficiencies that adversely affect system integrity (e.g., using system integrity statement provided by vendor).
2. Reviewed the operating system to determine if it had been configured to prevent circumvention of the security software and application controls. We used CA-Examine to analyze the software and hardware environment of the Masterfile OS/390 system.
3. Determined that vendor-supplied default logon identifiers and passwords had been disabled.
4. Determined if remote access to the system master console was restricted.
B. Determining the policies and techniques that had been implemented for using and monitoring use of system utilities. We determined if:
1. Policies and procedures for using and monitoring use of system software utilities existed and were up-to-date.
2. Responsibilities for using sensitive system utilities had been clearly defined and were understood by systems programmers.
3. Responsibilities for monitoring the use of system utilities were defined and understood by technical management.
4. The use of sensitive system utilities was logged using access control software reports or job accounting data (e.g., IBM’s System Management Facility).
C. Determining whether inappropriate or unusual activity was investigated and appropriate actions taken by determining if:
1. The use of privileged system software and utilities was reviewed by technical management.
2. Inappropriate or unusual activity in using utilities was investigated.
3. Systems programmers’ activities were monitored and reviewed.
4. Management reviews were performed to determine that control techniques for monitoring use of sensitive system software were functioning as intended and that the control techniques in place were maintaining risks within acceptable levels (e.g., periodic risk assessments).
D. Determining if system software changes were authorized, tested, and approved before implementation. We determined whether:
1. Policies and procedures existed and were up-to-date for identifying, selecting, installing, and modifying system software.
2. Procedures existed for identifying and documenting system software problems. These procedures normally include using a log to record the problem, the name of the individual assigned to analyze the problem, and how the problem was resolved.
3. New system software versions or products and modifications to existing system software received proper authorization and were supported by a change request document.
4. New system software versions or products and modifications to existing system software were tested and the test results were approved before implementation.
5. Procedures existed for controlling emergency changes.
E. Evaluating the installation of system software by determining if:
1. Installation of system software was scheduled to minimize the impact on data processing and advance notice was given to system users.
2. Migration of tested and approved system software to production use was performed by an independent library control group.
3. Installation of all system software was logged to establish an audit trail and reviewed by data center management.
4. Vendor-supplied system software was supported by the vendor.
5. All system software was current and had current and complete documentation.
IV. Determined whether controls over system resources provided reasonable assurance that data files, application programs, and computer-based facilities and equipment were protected against unauthorized modification, disclosure, loss, or impairment by:
A. Determining if resource classifications and related criteria had been established.
B. Determining if resource classifications were based on risk assessments and classifications were documented and approved by an appropriate senior official and were periodically reviewed.
C. Determining whether authorized users had been identified and their accesses authorized. We determined whether:
1. Policies and procedures for restricting access existed and were up-to-date.
2. Access authorizations were documented on standard forms and maintained on file, approved by senior managers, and securely transferred to security managers.
3. Access authorization listings were periodically reviewed.
4. Access to system software was restricted to a limited number of personnel, corresponding to job responsibilities; application programmers and computer operators were specifically prohibited from accessing system software; and update access was generally limited to primary and backup systems programmers.
5. The number of users who can dial into the system from remote locations was limited and justification for such access was documented and approved by owners.
6. Security managers reviewed access authorizations and discussed any questionable authorizations with resource owners.
7. All changes to security profiles by security managers were automatically logged and periodically reviewed by management independent of the security function and unusual activity was investigated.
8. Security was notified immediately when system users were terminated or transferred.
D. Identifying that emergency and temporary access authorization was controlled.
E. Determining how the resource owners determined the disposition and sharing of data. We determined whether:
1. Standard forms were used to document approval for archiving, deleting, or sharing data files.
2. Prior to sharing data or programs with other entities, agreements were documented regarding how those files were to be protected.
F. Evaluating the implementation of logical access controls by determining if:
1. Passwords, tokens, or other devices were used to identify and authenticate users.
2. An analysis of the logical access paths was performed whenever changes to the system were made.
3. Logical controls were in place to restrict access to the data files and software programs.
4. Security software was used to restrict access by evaluating whether:
· Security administration personnel set parameters of security software to provide access as authorized and restrict access that had not been authorized. These parameters include access to data files, load libraries, batch operational procedures, source code libraries, security files, and operating system files. We used the IBM Security Server to perform this work.
· Access to security software was restricted to security administrators only.
· Inactive users’ accounts were monitored and removed when not needed.
G. Determining if audit trails were maintained, identifying that all activity involving access to and modifications of sensitive or critical files was logged. We determined whether:
1. Actual or attempted unauthorized, unusual, or sensitive access was monitored.
2. Suspicious access activity was investigated and appropriate action taken.
Appendix
III
Scott E. Wilson, Associate Inspector General for Audit (Information Systems Programs)
Gary Hinkle, Director
Vincent J. Dell’Orto, Audit Manager
Myron Gulley, Senior Auditor
Michael Howard, Senior Auditor
Van Warmke, Senior Auditor
Kim McManis, Auditor
General Accounting Office Contributors:
Gregory Wilshusen, Assistant Director
Ed Glagola, Assistant Director
David Hayes, Assistant Director
Ronald Parker, Senior EDP Auditor
Denise Fitzpatrick, Information Systems Analyst
Commissioner N:C
Chief, Information Technology Services M:I
Director, Corporate Computing M:I:E
Director, Martinsburg Computing Center M:I:E:MC
Director, Office of Security M:S
Director, Strategic Planning and Client Services M:SP
Deputy Chief Financial Officer, Department of the Treasury
The response was
removed due to its size. To see the
response, please go to the Adobe PDF version of the report on the TIGTA Public
Web Page.
[1] The Masterfile system runs the OS/390 operating system, which is IBM’s standard operating system for its mainframe computers.
[2] High-risk components refers to system software that, if compromised, would likely result in the compromise of the integrity of the entire system.
[3] The Masterfile system runs the OS/390 operating system, which is IBM’s standard operating system for its mainframe computers.
[4] ***(b)(2), (b)(7)(E)***
[5] ***(b)(2), (b)(7)(E)***
[6] High-risk components refers to system software that, if compromised, would likely result in the compromise of the integrity of the entire system.