10.8.2  IT Security Roles and Responsibilities (Cont. 1)

10.8.2.2 
Roles and Responsibilities

10.8.2.2.1 
Key Governance and Related Roles & Responsibilities

10.8.2.2.1.17  (05-16-2014)
Employee

  1. The provisions of this IRM apply to individuals and organizations having contractual arrangements with the IRS, including employees (IRS personnel, consultants, detailees, temporary employees, interns and IRS contractors) which use or operate IT systems.

  2. IRS Employees shall:

    1. Comply with all executive, legislative, Department of Treasury and IRS security policies and procedures.

    2. Immediately report any incidents of loss or mishandling of IRS information technology resources to the IRS Computer Security Incident Response Center (CSIRC), their immediate supervisor, and the Treasury Inspector General for Tax Administration (TIGTA).

    3. Contact CSIRC in the event of a suspected incident (see http://www.csirc.web.irs.gov/about/contact.html).

    4. Follow directions given from the CSIRC during an incident or as suspicious activities are evaluated.

    5. Attend/complete an initial security briefing and acknowledge attendance at the security briefing in writing.

    6. Complete periodic (at least annual) refresher ATE/SATE training.

    7. Thoroughly read and abide by the Rules of Behavior for the systems consult the OL 5081 procedures, as well as associated policies and procedures to which personnel are granted access.

    8. Not have access to sensitive IT systems until they at least have a favorably adjudicated National Agency Check (a component of the full background investigation).

    9. Not access sensitive/classified IT systems until they have received the in brief for the appropriate clearance for the IT system.

    10. Complete and acknowledge the completion (e.g., signing Form 11370, electronic signature) of UNAX training is required.

    11. Be responsible for protecting any Sensitive But Unclassified (SBU) or Personally Identifiable Information (PII) that they have in their possession, whether it is paper-based or in electronic form.

    12. Receive training in acceptable computer security practices prior to system access, in addition to the Rules of Behavior (for all IRS employees involved with the management, operation, programming, maintenance, or use of IRS information systems).

    13. Immediately report any incidents of mishandling, tampering, or the loss of a laptop computer to IRS Information Technology Cybersecurity organization (see IRM 10.8.26, Laptop Computer Security Policy, for further guidance).

    14. Complete Security (ATE/SATE). Refer to IRM 10.8.1 for detailed training requirements.

    15. Escort visitors of IRS facilities.

  3. In accordance with IRM 10.8.1, employees shall:

    1. Protect Sensitive But Unclassified (SBU) data, including Personally Identifiable Information (PII), contained on IRS IT Systems and other forms of portable media from risk of disclosure or compromise.

    2. Minimize the threat of viruses from portable mass storage devices (including, but not limited to, flash disks, pen drives, key drives, and thumb drives), ensuring that these devices have no additional software or firmware beyond storage management and encryption. Also, never knowingly circumventing anti-virus safeguards.

  4. Employees with a laptop computer(s) shall follow all requirements as outlined in accordance with IRM 10.8.26.

  5. In accordance with IRM 10.8.27, employees shall:

    1. Refrain from using Government IT resources for activities that are inappropriate based on established Codes of Ethical Conduct for employees.

    2. Be responsible for their own personal and professional conduct and shall follow, among others, the rules and regulations described below.
      • The Office of Personnel Management (OPM) Employee Responsibilities and which states, "An employee shall not engage in criminal, infamous, dishonest, immoral, or notoriously disgraceful conduct, or other conduct prejudicial to the Government" (5 CFR § 735.203).

    3. Adhere to the Office of Government Ethics (OGE) Standards of Ethical Conduct states:
      • "Employees shall put forth honest effort in the performance of their duties…" (5 Code of Federal Regulation (CFR) § 2635.101(b)(5)).
      • "…an employee shall not use or permit the use of his Government position or title or any authority associated with his public office in a manner that could reasonably be construed to imply that his agency or the Government sanctions or endorses his personal activities" (5 CFR § 2635.702 (b)).
      • "An employee has a duty to protect and conserve Government Property and shall not use such property, or allow its use, for other than authorized purposes." (5 CFR § 2635.704(a)). Employee conduct pursuant to the IRM policy on limited personal use is considered an "authorized use" of government property as the term is used in 5 CFR § 2635.704(a). See TD 87-04(4)(e) (defining limited personal use).
      • "…an employee shall use official time in an honest effort to perform official duties" and "…in accordance with law or regulation…" (CFR § 2635.705).
      • The Department of the Treasury Employee Rules of Conduct states: (1) "Employees shall not engage in criminal, infamous, dishonest, or notoriously disgraceful conduct, or any other conduct prejudicial to the Government." (31 CFR § 0.213).

    4. Ensure that they do not give the false impression that they are acting in an official capacity when they are using Government IT resources for non-government purposes. In addition, they shall not post, disseminate, or otherwise use IRS documents and/or symbols as part of personal documents, Internet sites, or other forms of communication.
      • If there is an expectation that such a personal use could be interpreted to represent an agency, an adequate disclaimer must be used. One acceptable disclaimer is - "The content of this message is mine personally and does not reflect the position of the U.S. Government, the Department of the Treasury, or the IRS."

  6. In accordance with Treasury’s TDP 85-01, employees shall:

    1. Complete IT security awareness training annually.

    2. Read and abide by applicable ethics and appropriate use policies for IT systems.

    3. Read and abide by applicable rules of behavior for IT systems.

    4. Read and abide by applicable guidance regarding use of personally owned equipment to access IRS systems.

    5. Be accountable for IT assets assigned to them and protect those assets in accordance with applicable requirements.

    6. Know the security category of the data they handle and measures they must take to protect it.

    7. Notify the appropriate IRS contacts of any suspected security incidents in a timely manner, and cooperate in the investigation of such incidents.

    8. Obtain AO approval prior to connecting devices with camera or voice transmission or recording capabilities to IRS systems or networks.

    9. Only use IRS email accounts for performance of official duties.

    10. Not automatically forward email messages to non-IRS accounts.

    11. Not knowingly generate or distribute junk email (spam), spyware, adware, or malware via Federal systems or equipment.

10.8.2.2.1.18  (05-16-2014)
Contractor

  1. The provisions of this IRM applies to individuals and organizations having contractual arrangements with the IRS, including contractors, vendors, and outsourcing providers, which use or operate IT systems.

  2. Contractors shall:

    1. Be instructed on appropriate security procedures before being granted unescorted system access.

    2. Be subject to background investigations at the risk level appropriate to the sensitivity of the position and sensitivity/classification of the data.

    3. Not access sensitive IT systems until they have at least a favorably adjudicated National Agency Check (a component of the full background investigation).

    4. Be responsible for protecting any Personally Identifiable Information (PII) that they have in their possession, whether it is paper-based or in electronic form.

    5. Understand the provisions and applicable criminal penalties under Public Law 105-35, Taxpayer Browsing Protection Act, shall also apply to all contractors and contractor employees.

    6. Comply with all executive, legislative and Department of Treasury and IRS security policies and procedures.

    7. Minimize the threat of viruses by write-protecting removable media, routinely scanning files, systems and media for viruses and never circumventing anti-virus safeguards.

    8. Report any suspicious or unusual activity to the appropriate supervisor and CSIRC.

    9. Notify the CSIRC of any suspicious activities that may result in security incidents.

    10. Contact CSIRC (see http://www.csirc.web.irs.gov/about/contact.html ) in the event of a suspected incident.

    11. Follow directions given from the CSIRC during an incident or as suspicious activities are evaluated.

    12. Not access sensitive/classified IT systems until they have received the in brief for the appropriate clearance for the IT system.

    13. If involved with the management, operation, programming, maintenance, or use of IRS information systems, shall receive training in acceptable computer security practices prior to system access.

    14. Receive the same level of information security awareness and training as federal employees. While under contract to the IRS, contractors are responsible for ensuring that their employees are provided appropriate Security (ATE/SATE).

    15. Contractors with significant security responsibilities shall receive, at least annually, specialized security awareness training specific to their security role and responsibilities.

    16. Attend/complete an initial security briefing and acknowledge attendance at the security briefing in writing.

    17. Attend/complete periodic (at least annual) refresher training and briefings.
      Complete any acknowledgements (e.g., UNAX Form 11370).

    18. Thoroughly read and abide by the Rules of Behavior for the systems, as well as associated policies and procedures by which personnel are granted access.

  3. In accordance with IRM 10.8.1 :

    1. Protect Sensitive But Unclassified (SBU) data, including Personally Identifiable Information (PII), contained on IRS IT Systems and other forms of portable media from risk of disclosure or compromise.

    2. Minimize the threat of viruses from portable mass storage devices (including, but not limited to, flash disks, pen drives, key drives, and thumb drives), ensuring that these devices have no additional software or firmware beyond storage management and encryption. Also, never knowingly circumventing anti-virus safeguards.

  4. Contractors with an IRS-issued laptop computer(s) shall follow all requirements as outlined in accordance with IRM 10.8.26.

  5. In accordance with Treasury’s TD P 85-01, Contractors (End User) shall:

    1. Complete IT security awareness training annually.

    2. Read and abide by applicable ethics and appropriate use policies for IT systems.

    3. Read and abide by applicable rules of behavior for IT systems.

    4. Read and abide by applicable guidance regarding use of personally owned equipment to access IRS systems.

    5. Be accountable for IT assets assigned to them and protect those assets in accordance with applicable requirements.

    6. Know the security category of the data they handle and measures they must take to protect it.

    7. Notify the appropriate IRS contacts of any suspected security incidents in a timely manner, and cooperate in the investigation of such incidents.

    8. Obtain AO approval prior to connecting devices with camera or voice transmission or recording capabilities to IRS systems or networks.

    9. Use IRS email accounts for performance of official duties.

    10. Not automatically forward email messages to non-IRS accounts.

    11. Not knowingly generate or distribute junk email (spam), spyware, adware, or malware via Federal systems or equipment.

10.8.2.2.1.19  (05-16-2014)
Database Administrator (DBA)

  1. The Database Administrator (DBA) shall perform all activities related to maintaining a correctly performing and secure database environment. Responsibilities include design (in conjunction with application developers), implementation, and maintenance of the database system as described in IRM 10.8.21 and associated IRMs.

  2. The primary security role of any Database Administrator (DBA) is to administer and maintain database repositories for proper use by authorized individuals.

  3. Individuals assigned security responsibilities for DBMS environments, including the SecSpec and DBA, shall obtain database security technical training necessary to implement the requirements of this IRM. The training shall cover the security features specific to the DBMS products the individuals are required to support.

  4. Database Administrator role accounts shall have the least level of elevated privileges required to perform DBA-related duties and shall not include root or root-level access. DBAs who require the ability to perform certain system administrator functions such as account creation or the editing of system configuration files shall use a separate system administrator role account that provides these capabilities.

  5. At a minimum, the DBA shall:

    1. Establish security for database objects within the database and for the DBMS according to IRS security policies.

    2. Support disaster/recovery planning, documentation and implementation efforts for the database(s).

    3. Establish database points of consistency.

    4. Coordinate with the SA to integrate database backups into the system related backup and recovery, including creating the backups if necessary.

    5. Periodically test backup copies of the databases.

    6. Recover the database to a current or previous state, if necessary.

    7. Recover individual objects (e.g., data rows, etc.) to a current or previous state;

    8. Identify database requirements of system resources.

    9. Provide network requirements for the database to the organizations responsible for designing and implementing network services.

    10. Manage the database configuration (e.g., architecture, internal settings, etc.) according to the certified and accredited operating system security configuration;

    11. Support Security Assessments and Authorization efforts.

    12. Monitor/manage database performance and capacity.

    13. Monitor user activities where appropriate.

    14. Enable and configure audit logging on all IRS systems in accordance with IRM 10.8.3, and all other applicable configuration IRMs.

10.8.2.2.1.20  (05-16-2014)
Encryption Recovery Agent

  1. Encryption Recovery Agents shall be required for the safe recovery of data, whenever encryption keys are lost or compromised.

  2. The role of Encryption Recovery Agents shall be established in all organizations that administer IT systems with encryption and resources.

  3. Business and functional unit owners shall establish policies and procedures for the administration of recovery agents for all IT environments.

  4. In accordance with NIST Special Publication 800-57, Recommendation for Key Management – Part 1: General (Revision 3) (dated July 2012), Encryption Recovery Agents shall be responsible for:

    1. The keying material that needs to be saved for a given application.

    2. How and where the keying material would be saved.

    3. Who shall be responsible for protecting the Key Recovery Information (KRI), whether it be an individual or an external organization.

    4. Who can request key recovery and under what conditions.

    5. What audit capabilities and procedures would be included in the Key Recovery System (KRS), including a policy which identifies the events to be audited.

    6. How the KRS would deal with aged keying material or the destruction of the keying material.

    7. Who would be notified when keying material is recovered and under what conditions.

    8. The procedures that need to be followed when the KRS or some portion of the data within the KRS is compromised.

  5. The Encryption Recovery Agent shall provide support during key recovery procedures.

10.8.2.2.1.21  (05-16-2014)
Network Administrator

  1. Network Administrators (NAs) shall be responsible for the day-to-day administration of the network devices under their purview.

  2. At a minimum, the NA shall:

    1. Configure network device parameters within the documented security standards, using the applicable IRMs, policies and system life cycle documentation.

    2. Ensure the proper installation, testing, protection and use of network device software, including installing network software fixes and upgrades.

    3. Maintain the configuration of wireless networks or network devices under his/her control in accordance with the requirements of IRM 10.8.40, Wireless Security.

    4. Enable and configure audit logging on all IRS systems in accordance with IRM 10.8.3, and all other applicable configuration IRMs.

    5. Maintain current documentation that properly defines the hardware and software configuration of the network devices and connections for which they are responsible.

    6. Ensure inventories are accurately maintained.

    7. Recommend and implement processes, changes and improvements to programs, procedures and network devices.

    8. Monitor network performance; performing network diagnostics; analyzing network traffic patterns.

    9. Support disaster recovery planning, documentation, and implementation efforts for the network.

  3. The NA shall support CSIRC efforts and security incident handling.

  4. The NA shall apply patches and hot fixes as directed, following configuration management policies and procedures. Refer to IRM 10.8.50, for further information concerning security patch management.

10.8.2.2.1.22  (05-16-2014)
Program Developer/Programmer

  1. Program Developers/Programmers shall be responsible for the development, testing and maintenance of application programs.

  2. At a minimum, Program Developers/Programmers shall:

    1. Develop application programs in accordance with established organizational policies and procedures.

    2. Develop application programs in accordance with IRM 10.8.1 and IRM 10.8.6.

    3. Adhere to IRS Configuration Management (CM) practices and the ELC requirements.

    4. Create installation scripts, processes, and instructions for production organizations to utilize. The developer shall incorporate feedback mechanisms into the installation processes as needed.

10.8.2.2.1.23  (05-16-2014)
Web Developer

  1. In accordance with IRM 10.8.22, the Web Developer shall be responsible for:

    1. Development of Web sites and applications, including creating/manipulating/implementing graphic images and formulating documentation for Web sites and Web applications in accordance with IRM 10.8.1.

    2. Formulating specification requirements, producing level of effort estimates, providing informational support to security certifications, and performing Web server and Web application server project planning, scheduling, and testing.

10.8.2.2.1.24  (05-16-2014)
Resource Access Control Facility (RACF) Specialist

  1. A System Software RACF Specialist is in the System Administrator (SA) role with a subset of the generic System Administrator (SA) responsibilities. The System Software RACF Specialists, in coordination with the operating system program developer(s), systems operations staff, and the RACF Security Administrator (RSA), shall identify and install all critical system resources, components, data sets, and connections which are to be protected by RACF. The RACF software specialist works with the RSA to determine the appropriate access control levels and monitoring requirements for system resources by:

    1. Configuring system parameters within the documented security standards, using the applicable IRMs and system life cycle documentation.

    2. Maintaining current documentation that properly defines the technical hardware and software configuration of system and network connections.

    3. Starting up and shutting down the system.

    4. Ensuring regular backups, recovery tests, and other associated contingency planning responsibilities for systems are performed.

    5. Monitoring system/user access for performance concerns.

    6. Performing application management activities.

  2. (RSA) functions within the SA role and shall work with the system software RACF Specialist to perform the initial setup of the RACF system and maintain user/group access profiles. The RSA has overall responsibility for all security matters within RACF. The subset of generic SA responsibilities shall include at a minimum:

    1. Establishing and maintaining least privilege user roles and the role based access matrix outlining the access for each role.

  3. RACF Group Administrator functions within the SA role with the same generic SA responsibilities as the RSA. Distributed security administration is allowed, but not required. RACF Group Administrators shall have overall responsibility for all security matters within the scope of their group.

  4. RACF User Administrator functions within the user administrator role. (Refer to the User Administrator (UA) section of this IRM for general requirements). RACF User Administrators (RUA) shall perform user account administration under the direction of a RSA or RACF Group Administrator.

    1. Establishing the RACF User Administrators using the OL 5081 process for user administration requests, while routing the request to the appropriate non-SA (e.g., Account Administrator staff or other user administrator) for processing.

  5. RACF System or Group Auditor functions within the SecSpec role. (Refer to the Security Specialist (SecSpec) section of this IRM for general requirements). In order to provide a system of checks and balances, independent auditor(s) are assigned at the system or user group level and shall review user activities in areas where they perform no activities relating to administration, programming, or security administration.

  6. In the mainframe environment, the RACF software specialist installs the RACF product and identifies security critical system resources. The RSA shall have the responsibility for maintaining RACF resource profiles and user roles.

10.8.2.2.1.25  (05-16-2014)
Security Specialist (SecSpec)

  1. The SecSpec shall be responsible for reviewing all activities of the SAs, NAs, DBAs, anyone responsible for the operation or administration of IT equipment, anyone involved with user administration, such as the EAA staff, and all other users to ensure they are compliant with security requirements.

  2. The SecSpec shall oversee any and all user (e.g., system, database, application, etc.) administration regardless of how or who performs it.

  3. Additionally, the SecSpec shall:

    1. Ensure the site contingency plans remain up-to-date in response to new security requirements or changes in the IRS IT architecture.

    2. Conduct and support all security reviews of IRS systems and networks.

    3. Provide or recommend security measures and countermeasures based on the security reviews and security policies.

    4. Upon management request, review individual user's access verifying it is the least privilege necessary to perform his/her job.

    5. Inspect and monitor user files, as directed by management.

    6. Conduct security audits, verifications and acceptance checks, while maintaining documentation on the results.

    7. Promote security awareness and compliance.

    8. Report security incidents including those discovered while reviewing audit logs/trails.

    9. Assist with developing a deviation request, such as interpreting policy to determine if a deviation is required, assisting with the risk assessment and possible mitigations.

  4. The SecSpec shall review all types of audit logs/trails and observe system activity at least weekly in order to:

    1. Ensure integrity, confidentiality and availability of information and resources.

    2. Detect inappropriate user and system actions that could be construed as security incidents.

    3. Investigate possible security incidents.

    4. Monitor user or system activities where appropriate.

  5. A SecSpec shall not perform system/security administration on any system/platform/application, etc.

  6. The SecSpec shall have read-only access to system resources and shall not modify audit settings.

  7. In accordance with IRM 10.8.3, SecSpecs shall:

    1. Be familiar with the requirements and procedures specified in IRM 10.8.3 and its exhibits.

    2. Notify their management of any implementation discrepancies between the requirements of IRM 10.8.3 and the actual audit logging status of systems that the SecSpecs support.

    3. Follow any applicable organizational-level incident reporting procedures (such as contacting management, system administrators, or the Computer Security Incident Response Center in the event that evidence of suspicious activity is discovered in the course of reviewing security audit log information.

  8. In accordance with IRM 10.8.21, the IT SecSpec shall be concerned with the security and integrity of the database and responsible for:

    1. Obtaining database security technical training necessary to implement the requirements of this IRM. The training shall cover the security features specific to the DBMS products the individuals are required to support.

    2. Ensuring that the requirements of IRM 10.8.1 and IRM 10.8.21 are met.

    3. Ensuring that DBAs, System Administrators (SAs), and others having daily operational responsibilities for IRS databases comply with the security requirements of IRM 10.8.21. In general, the SecSpec is not expected to personally implement the requirements, but rather ensure that others do so.

    4. Report IRM non-compliance issues initially to DBAs and SAs for resolution, and escalate non-compliance reporting to IRS management officials (such as the ISSO and Information System Owner) as necessary to bring systems into compliance with IRM 10.8.21.

  9. In accordance with IRM 10.8.10, the SecSpec shall:

    1. Review all activity of administrators and those responsible for administration of IT equipment.

    2. Ensure that SAs and others having daily operational responsibilities for IRS Linux/Unix servers and workstations comply with the security requirements of this IRM. The SecSpec is not expected to personally implement the requirements but shall ensure that others do so.

    3. Report Windows IRM non-compliance issues initially to Information System Owner and SAs for resolution, and escalate non-compliance reporting to IRS management officials as necessary to bring systems into compliance with IRM 10.8.20.

    4. Not have operating System Administrator privileges.

  10. In accordance with IRM 10.8.20, the SecSpec shall:

    1. Review all activity of administrators and responsible for administration of IT equipment.

    2. Ensure that SAs and others having daily operational responsibilities for IRS Windows servers and workstations comply with the security requirements of this IRM. The SecSpec is not expected to personally implement the requirements but shall ensure that others do so.

    3. Report Windows IRM non-compliance issues initially to Information System Owner and SAs for resolution, and escalate non-compliance reporting to IRS management officials as necessary to bring systems into compliance with IRM 10.8.20.

    4. Not have operating System Administrator privileges.

  11. In accordance with IRM 10.8.22, the SecSpec shall:

    1. Ensure that the requirements of IRM 10.8.22 are met.

    2. Ensure that SAs and others having daily operational responsibilities for IRS Web servers and Web application servers comply with the security requirements of IRM 10.8.22.

    3. Report IRM non-compliance issues initially to Information System Owner and SAs for resolution, and escalate non-compliance reporting to IRS management officials as necessary to bring systems into compliance with IRM 10.8.22.

  12. Support Security Assessments and Authorization efforts; controls testing (monthly and annual), contingency testing, documentation development, POA&M weakness correction, and ongoing security vulnerability remediation efforts.

10.8.2.2.1.26  (05-16-2014)
System Administrator (SA)

  1. System Administrators (SAs) shall be technicians who administer, maintain, and operate information systems. They are responsible for implementing technical security controls on computer systems and for being familiar with security technology that relates to their system.

  2. At a minimum, (non-RACF) SAs shall:

    1. Add, remove, maintain system users and configure their access controls to provide the users necessary access with least privilege, as defined for each user in the OL 5081.

    2. Provide lists of system users for systems under his/her control and providing the lists to the appropriate users' managers and appropriate SecSpecs for review, update and certification.

    3. Configure system parameters within the documented security standards, using the applicable IRMs and system life cycle documentation.

    4. Maintain current documentation that properly defines the technical hardware and software configuration of system and network connections for systems they are responsible.

    5. Ensure the proper installation, testing, protection, and use of system and application software.

    6. Install and manage application server software including development tools and libraries, software compilers, code builds, and middleware interfaces between servers and application servers and back-end storage media in accordance with IRM 10.8.6.

    7. Install and manage servers and workstation software in accordance with the applicable IRM for the OS in use.

    8. Start up and shut down the system.

    9. Perform regular backups and recovery tests and other associated contingency planning responsibilities for systems for which they are responsible.

    10. Enable, configure, and archive audit logs/trails and system logs for review by the SecSpecs for all IRS systems in accordance with IRM 10.8.3, and all other applicable configuration IRMs.

    11. Monitor system/user access for performance and security concerns.

    12. Establish conditions on the system so that other operational entities can perform application management activities.

    13. Run various utilities and tools in support of the SecSpecs.

  3. The SA shall be responsible for supporting the SecSpec's needs for read access to system resources as defined in the access control request (e.g., OL 5081).

  4. The SA shall support techniques that allow non-SAs to perform user administration in a controlled and limited manner while still managing access to system resources and other directories and files.

  5. The use of non-SAs for user administration shall be documented in the Computer Operations Handbook or equivalent for the system/application and in the Security Assessments and Authorization documentation for the relevant GSS and application.

  6. The use of non-SAs for user administration shall be established via a Memorandum of Agreement (MOA) and accepted by the involved (AO)s.

  7. Depending on the environment, the SA may perform user support for password issues. This can include (but is not limited to) resetting or issuing a new password when the user forgets the current one or locks the account.

  8. The SA shall support CSIRC efforts and security incident handling.

  9. The SA shall install security patches in a timely and expeditious manner based on CSIRC’s criticality designation.

  10. The SA shall apply patches and hot fixes as directed, following configuration management policies and procedures and contact IRS Information Technology Cybersecurity organization for further information concerning security patch management.

  11. Support ISCP and DR Plan development and accuracy.

10.8.2.2.1.27  (05-16-2014)
Systems Operations Staff

  1. The role of the Systems Operations Staff is assigned to the IRS, Enterprise Operations organization.

  2. Systems Operations Staff shall:

    1. Safeguard equipment, data, and magnetic media during day-to-day performance of their duties.

    2. Be able to perform System Administrator (SA) duties delegated them from the SA with associated least privilege permissions to perform those functions.

10.8.2.2.1.28  (05-16-2014)
Telecommunications Specialist

  1. The role of Telecommunication (Telecomm) Specialist is assigned to the IRS, User and Network Services Organization (UNS).

  2. The (UNS) organization is responsible for providing communications services, including voice, data, video, and fax service.

  3. The Telecomm Specialist shall be responsible for the management of the communication systems in compliance with IT security policy and federal regulations.

  4. The Telecommunications Specialist shall support ISCP and DR Plan development, accuracy, documentation, and implementation efforts for their system(s).

10.8.2.2.1.29  (05-16-2014)
User Administrator (UA)

  1. The User Administrator (UA) role pertains only to organizations (e.g., Enterprise Service Desk - Enterprise Account Administration (ESD-EAA), etc.) who provide the service.

  2. The UA shall have no more capability than appropriate to establish a user on a system or to establish a user within an application.

  3. The UA shall use the IRS approved access control (e.g., OL 5081) process.

  4. An SA or NA establishing user access does not assume this role.

10.8.2.2.1.30  (05-16-2014)
Live Data Functional Coordinator (LDFC)

  1. In accordance with IRM 10.8.8, Live Data Protection, the collateral duty role of Live Data Functional Coordinator (LDFC) shall be assigned. The primary role of the LDFC is to serve as a partner with developers/testers, their managers, and reviewers/approvers of requests to use live data. In addition, the LDFC is the point of contact for management during security/disclosure/privacy compliance reviews and oversight audits of the use of live data.

  2. Each business and operating division shall identify one or more LDFCs. Considering the frequency of use and geographic distribution of employees, the organization shall select enough coordinators to successfully perform the responsibilities outlined below. For example, in the New Carrollton Federal Building (NCFB) each business and operating division should have at least one.

  3. The LDFC shall comply with all aspects of IRM 10.8.8 and shall assist:

    1. IT Specialists and managers in understanding when it is permissible to use live data.

    2. Originators of request forms in fully and accurately completing the forms.

    3. Reviewers and approvers in using the manager's checklist to properly review live data requests.

    4. Managers in performing live data compliance.

    5. Managers in maintaining complete and accurate files of request forms/manager's checklists (approved and disapproved); records of transmittals of request forms/manager's checklists to the operational sites supplying the data; GSS supplying the data; and documentation of live data compliance.

  4. The LDFC shall provide Security/disclosure/privacy/oversight in accessing the files in e) above during compliance reviews or audits and maintain accurate records of those reviews for future audit.

10.8.2.2.1.31  (05-16-2014)
Integrated Data Retrieval System (IDRS) Security Analyst

  1. In 2009, to help ensure proper separation of duties, IDRS security user and unit account administration migrated from Cybersecurity Operations to the Enterprise Operations, Operational Security Program Management Office (EOPSOSPMO). Cybersecurity Operations will continue to perform IDRS security policy support and oversight related tasks.

  2. The IDRS Security Officer role has been replaced with two new roles:

    1. The IDRS Security Account Administrator performs the user and unit account administration tasks previously performed by the IDRS Security Officer.

    2. The IDRS Security Analyst performs the policy support and oversight tasks previously performed by the IDRS Security Officer.

  3. The IDRS Security Analyst performs IDRS security policy support and oversight related tasks for IDRS campus domains and/or IDRS computing centers.

  4. The Integrated Data Retrieval System (IDRS) Security Analyst shall be a non-bargaining unit employee who is a member of the Cybersecurity Operations staff.

  5. For additional related responsibilities, refer to IRM 10.8.34.

10.8.2.2.1.32  (05-16-2014)
Integrated Data Retrieval System (IDRS) Security Account Administrator

  1. In 2009, to help ensure proper separation of duties, IDRS security user and unit account administration migrated from Cybersecurity Operations to the Enterprise Operations, Operational Security Program Management Office (EOPSOSPMO). Cybersecurity Operations will continue to perform IDRS security policy support and oversight related tasks.

  2. The IDRS Security Officer role has been replaced with two new roles:

    1. The IDRS Security Account Administrator performs the user and unit account administration tasks previously performed by the IDRS Security Officer.

    2. The IDRS Security Analyst performs the policy support and oversight tasks previously performed by the IDRS Security Officer.

  3. The IDRS Security Account Administrator performs tasks relating to the administration of IDRS user and unit accounts.

  4. The IDRS Security Account Administrator shall be a non-bargaining unit employee who is a member of the Security Operations & Standards Division (EOPS-SOSD) staff.

  5. To help ensure proper separation of duties, the IDRS Security Account Administrator shall not simultaneously serve as Computing Center IDRS Security Administrator.

  6. The IDRS Security Account Administrator shall maintain a current list of Unit Security Representatives (USRs), alternate USRs, Terminal Security Administrators (TSAs), managers, and the designated Primary Recipients for all IDRS units in the IDRS Unit and USR Database (IUUD). To the extent practical, this listing should be complete and accurate and include at least the following information:

    1. Name

    2. SEID

    3. Division business unit

    4. Name of unit or function

    5. IDRS unit number(s) covered

    6. Telephone number

    7. IDRS unit security role

    8. Business mailing addresses

    9. Indicate when command code ASNPW is in the individual’s profile.

  7. For additional related responsibilities, refer to IRM 10.8.34.

10.8.2.2.1.33  (05-16-2014)
Computer Audit Specialist

  1. The Computer Audit Specialist (CAS) security role, which is specific to IRS business units (e.g., Large Business and International (LB&I)), shall be responsible for working with taxpayer records in which these records are formatted in a usable format for team members. These formats may be unique to the taxpayer and may involve the use of many different tools and programs.

  2. CAS shall load, run and configure software and services on machines to meet examination objectives. This may require them to add and remove device drivers and install/uninstall various programs as needed to work with the taxpayer records.

  3. CAS shall have the ability to add, configure and remove software. This will allow them to run multiple types of audits, whose software package may not be compatible with one another as a result cannot be installed and loaded onto a particular system simultaneously.

10.8.2.2.1.34  (05-16-2014)
Functional Workstation Specialist

  1. The Functional Workstation Specialist shall include, but not be limited to the following responsibilities:

    1. Have a full analytical and operational knowledge of specific software applications in order to resolve systemic & procedural problems and user errors thereby enabling the user to perform all tasks related to their jobs.

    2. Have a working knowledge of operating systems, protocols, and equipment used in business customer organizations.

    3. Have a working knowledge of methods and practices for troubleshooting, recovering, modifying, and improving application files.

    4. Utilize extensive problem solving skills and limited elevated permissions in order to diagnose and troubleshoot application problems in the performance of customer support.

    5. Have a working knowledge of all BOD processes including field, support functions and the Campuses.

    6. Act as a liaison between the Area/Territory Offices, Campus, and National Office.

    7. Provide both oral and written communication to all users levels (including Area Managers, Territory Managers, Group Managers, etc.).

    8. Coordinate activities relating to the security posture of the application with responsible business units and IRS Information Technology (UNS, EOPS, AD) staff.

    9. Forward problem descriptions to the appropriate personnel as these individuals are often the first to encounter application problems.

    10. Coordinate reporting within the Business Unit to ensure workstations are in compliance for consistency purposes.

    11. Ability to perform in an instructor capacity by conducting training and security awareness programs.

    12. Educate & communicate to end users security awareness and practices in the context of performing these and other tasks.

    13. Analyze and evaluate the effectiveness of system operations and make recommendations to correct deficiencies. Develops plans, goals, & objectives for long-range implementation and administration of program activity.

    14. Ensure adequate physical security controls are implemented at the workstation level.

    15. Provide technical direction to users who ensure the confidentiality, integrity, and availability of the tax systems.

    16. Consult with users to ensure they have applied patches and hot fixes as directed following configuration management policies and procedures in compliance with the IRM for purposes of application support.

    17. Escalate IT security matters to the respective party(s) as defined in local guidance.

    18. General knowledge of Disaster Recovery/Contingency Planning terminology and concepts.

10.8.2.2.1.35  (05-16-2014)
Management/Program Analyst

  1. The Management/Program Analyst, in support of meeting FISMA requirements, shall:

    1. Perform analytical studies affecting agency program operations.

    2. Analyze and evaluate the effectiveness of program operations and make recommendations to correct deficiencies.

    3. Develop plans, goals, & objectives for long-range implementation and administration of program activity.

10.8.2.2.1.36  (05-16-2014)
System Designer

  1. System Designers shall be responsible for developing, implementing, and monitoring polices and controls to ensure data accuracy, security and legal regulatory compliance throughout the system lifecycle.

  2. System Designers shall assist in the:

    1. Review and approval of products to ensure they incorporate and meet IRS security requirements.

    2. Planning, documentation and integration of security into a system’s lifecycle from its initiation to its disposal phases.

  3. System Designers shall be responsible for identifying IT assets and determining their value for establishing implementation security safeguard priorities.

  4. System Designers (a.k.a. System Developers) shall ensure Security Testing and Evaluations (ST&E) are conducted during the different stages of a system’s life cycle in accordance with IRM 10.8.1 (e.g., SA-11 Developer Security Testing and Evaluation) and NIST SP 800-64, Security Considerations in the System Development Life Cycle.

    1. See IRM 10.8.1 (e.g., SA-11 Developer Security Testing and Evaluation) for additional ST&E requirements.

10.8.2.2.1.37  (05-16-2014)
Technical Support Staff (Desktop)

  1. The Technical Support staff shall educate end-users in security procedures and practices in the context of performing their tasks.

10.8.2.2.1.38  (05-16-2014)
Physical Security Analyst

  1. The Physical Security Analyst is responsible for the support, implementation, oversight and management of physical security controls across the IRS, including integration with applicable information security controls. The Physical Security Analyst is considered an “expert” in Physical Security standards and guidance.

  2. The Physical Security Analyst supports the Director, Physical Security and Emergency Preparedness.

  3. The Physical Security Analyst shall:

    1. Review, develop, implement, and monitor the organization’s Physical Security Programs, to include appropriate controls for alternate work sites.

    2. Review organizational implementation and monitoring of access controls (i.e., authorization, access, visitor control, transmission medium, display medium, logging) are in accordance with NIST, Treasury and IRS Physical Security standards and guidance.

    3. Coordinate organizational environmental controls (i.e., ongoing and emergency power support and backups, fire protection, temperature and humidity controls, water damage).

    4. Review and oversee controls for delivery and removal of assets.

10.8.2.2.1.39  (05-16-2014)
Physical Security Specialist

  1. The Physical Security Specialist is responsible for the implementation and oversight of physical security controls across the IRS, including integration with applicable information security controls.

  2. The Physical Security Specialist supports the Physical Security Analyst.

  3. The Physical Security Specialist shall:

    1. Review, develop, promulgate, implement, and monitor the organization’s Physical Security Programs, for the protection of employees, equipment and property at all IRS facilities.

    2. Review organizational implementation and monitoring of access controls (i.e., authorization, access, visitor control, transmission medium, display medium, logging) to ensure they are in accordance with NIST, Treasury and IRS Physical Security standards and guidance.

10.8.2.2.1.40  (05-16-2014)
Cyber Critical Infrastructure Protection (CIP) Coordinator

  1. The Cyber Critical Infrastructure Protection (CIP) Coordinator is designated by the CIO/CTO. In this role, the IRS Cyber CIP Coordinator shall:

    1. Act as the primary point of contact for addressing IRS CIP issues with Treasury.

    2. Participate in CIP Assessments and critical infrastructure for the IRS.

    3. Maintain a prioritized list of critical infrastructure for the IRS.

    4. Participate in all CIP Working Group meetings.

    5. Provide coordination and collaboration among stakeholders on all IRS Cyber CIP activities.

    6. Determine the IRS Cyber Security Program status relative to the Plan’s objectives.

10.8.2.2.2  (07-12-2010)
Organization/Functional Roles and Responsibilities

  1. This section provides functional roles and responsibilities for personnel who have security related responsibility for the protection of information systems they operate, manage and support. These roles are defined in accordance with FISMA, NIST, OMB, TD P 85-01 and IRS Policy and Guidelines.

10.8.2.2.2.1  (05-16-2014)
IRS Information Technology Cybersecurity Organization

  1. In collaboration with the Business and Functional Unit Owner, the IRS Information Technology Cybersecurity organization shall:

    1. Develop, publish, and disseminate security policy.

    2. Develop security controls for systems and applications.

    3. Conduct annual testing of the systems and applications.

    4. Test and validate the effectiveness of corrective actions.

    5. Ensure ISCP and DR requirements are addressed for all applications and systems owned by IRS Information Technology Cybersecurity organization.

    6. Implement corrective actions and validate fixes to mitigate vulnerabilities assigned to IRS Information Technology Cybersecurity.

    7. Create and implement configuration management plans that control changes to systems and applications during development.

    8. Track security flaws, require authorization of changes, and provide documentation of the configuration management plan and its implementation.

  2. For DR and ISCP, the IRS Information Technology Cybersecurity organization shall:

    1. Jointly develop the detailed content of each DR plan to include recovery of the system, the application, and the associated data, including all platforms applicable to the system/application.

    2. Ensure requirements, priorities, recovery times, and costs of each DR plan are appropriate and achievable.

    3. Support the exercise of the ISCP.

    4. Ensure maintenance and update to the content of the DR plans by BU.

    5. Support procurement activities to enhance DR capabilities to meet stated business objectives.

    6. Ensure DR equipment located at recovery locations for the business units are maintained.

    7. Ensure establishment of DR location(s) based on FISMA, NIST, and IRS DR policy and requirements.

    8. Ensure offsite storage of data needed for recovery and ongoing backup of data.

    9. Establish a schedule and notify IRS Information Technology Cybersecurity and the impacted BU of the schedule for coordinating ISCP/DR exercises and tests throughout the year.

    10. Annually test each major system and establish DR testing priorities.

    11. Work with business units and IRS Information Technology Cybersecurity organization to resolve (if possible) issues identified during DR testing or document reasons/risk/impact.

    12. Refer to IRM 10.8.60.

  3. In accordance with IRM 10.8.3, IRS Information Technology Cybersecurity organization shall:

    1. Develop security controls for systems and applications.

    2. Develop and implement an IRS-wide time server, in accordance with IRM 10.8.3.

    3. Maintain and disseminate IRM 10.8.3.

    4. Establishing sufficient controls to ensure equipment is used appropriately.

    5. Ensure evidence is preserved for potential prosecution in lieu of immediate eradication; detailed instructions from CSIRC (or possibly TIGTA) shall be given to SAs, network administrators (NAs), and other key personnel on how to preserve the evidence.

  4. As with employees, IRS Information Technology organization shall notify the CSIRC of suspicious activities and shall comply with CSIRC directions.

    1. IRS Information Technology organization shall comply with their internal configuration management requirements.

    2. IRS Information Technology organization shall perform containment activities.

10.8.2.2.2.2  (05-16-2014)
IRS Information Technology User and Network Services Organization (UNS)

  1. In accordance with IRM 10.8.54, IRS Information Technology User and Network Services Organization (UNS) shall administer the firewall devices comprising the perimeter firewall environment.

  2. The UNS, Engineering and Capacity Management (EC&M) shall design the IRS network perimeter Demilitarized Zone (DMZ), including firewall requirements, and work directly with IRS Information Technology (UNS), Network Operations Support Services (NOSS) on its implementation and maintenance.

  3. The IRS Information Technology NOSS shall ensure that the IRS minimum firewall requirements and policies are met.

  4. The IRS Information Technology NOSS shall provide administration, operation and maintenance (OA&M) for the firewall devices comprising the perimeter firewall environment. This includes, but is not limited to:

    1. Implementing CSIRC-approved Firewall Change Requests (FCRs).

    2. Troubleshooting access problems.

    3. Applying security patches and software updates.

    4. Refreshing hardware.

    5. Securing maintenance contracts.

  5. The Information System Owner for IRS Information Technology User and Network Services Organization (UNS):

    1. Be responsible for notifications and routing of information to the appropriate organizational points-of-contact (POCs).

    2. Notify CSIRC of any Knowledge Incident/Problem Service Asset Management (KISAM) ticket needing CSIRC’s attention.

    3. Notify CSIRC for a user’s problem that originated with the Enterprise Service Desk.

    4. Report suspicious activity or incidents.

  6. The IRS Information Technology (UNS), Network Operations Management (NOM) shall monitor the ″up/down″ status of the network and firewall devices in the IRS network perimeter DMZ.

10.8.2.2.2.3  (09-05-2012)
Computer Security Incident Response Center (CSIRC)

  1. In accordance with FISMA (§ 3546), Computer Security Incident Response Center (CSIRC) shall:

    1. Provide timely technical assistance to operators of agency information systems regarding security incidents, including guidance on detecting and handling information security incidents.

    2. Compile and analyze information about incidents that threaten information security.

    3. Inform operators of agency information systems about current and potential information security threats, and vulnerabilities.

    4. Consult with the NIST, agencies or offices operating or exercising control of national security systems (including the National Security Agency), and such other agencies or offices in accordance with law and as directed by the President regarding information security incidents and related matters.

  2. In accordance with IRM 10.8.40, the CSIRC shall operate and maintain a wireless intrusion detection system.

  3. In accordance with TD P 85-01, IRM 10.8.1, and IRM 10.8.50, the CSIRC shall:

    1. Define relevant patches, prompting their implementation, and reporting their disposition.

    2. Designate which patches are security-related patches subject to service-wide security patch management policies and procedures.

    3. Notify IRS management of critical vulnerabilities and patches to facilitate timely actions.

    4. Review various sources for security-related system and application patches.

    5. Coordinate with external (to IRS) organizations to remain current on known vulnerabilities, exploits, and patches.

    6. Publish vulnerability alerts, advisories, and bulletins on the CSIRC web site, http://www.csirc.web.irs.gov/. See Exhibit 10.8.50-1 for a sample advisory.

    7. Provide the PVG with educational materials and information for distribution.

    8. Maintain a Security Notification Mailing List, which includes the email addresses of all PVG members and other designated personnel.

    9. Support Business and Functional Unit Owners by creating risk management plans for vulnerabilities that do not have patches or when patches cannot be applied.

    10. Assist Business and Functional Unit Owners with patch implementation process.

    11. Maintain a Patch Inventory.

    12. Assign a severity level and associate an implementation schedule with each advisory.

    13. Follow the procedures in this policy for advisory processing.

    14. Chair the PVG.

    15. Send approved advisories as email messages to the PVG members. The email subject line of an advisory shall contain, IRS Patch Advisory <Advisory Number> <Alert Level> <Color Code> <Title>.

  4. In accordance with IRM 10.8.1 , the CSIRC shall:

    1. Establish and manage the IRS computer security incident handling capability.

    2. Establish and maintain the policies for the IRS security incident handling capability.

    3. Have four basic functions defining the Incident Management Lifecycle:
      •Prevention
      •Detection
      •Response
      •Reporting

    4. Track and document information system security incidents on an ongoing basis.

    5. Actively and continuously monitor IT resources, to include but not limited to firewalls, wireless, network-based and host-based intrusion detection systems (IDSs) and event records, watching for suspicious cyber activities (termed, "suspicious activities," within IRM 10.8.1).

    6. Conduct offline/passive monitoring of logs from IDSs, firewalls, Web servers, and critical hosts, watching for possible security incidents.

    7. Inform Treasury Inspector General for Tax Administration (TIGTA) of suspected criminal activities, following established procedures in the Memorandum of Understanding with TIGTA.

    8. Perform routine vulnerability assessments (announced and unannounced Note: These assessments include active/passive monitoring, system and network scanning to support Security Assessments and Authorization processes, etc.).

    9. Serve as front line/1st tier support for security alerts.

    10. Perform initial analyses to determine validity, applicability, impact, and risks from potential security incidents.

    11. Record all detected intrusion attempts and report such events.

    12. Ensure that forensic evidence is properly collected and retained when investigating computer and network security incidents.

    13. Promptly reports incident information to appropriate authorities.

    14. Maintain an Incident Handling Contact List of personnel that are involved in security incident handling activities. The list shall include the contacts' various pager and phone numbers so they can be reached in the event of a security incident.

    15. Employ automated mechanisms to assist in the tracking of security incidents and in the collection and analysis of incident information.

    16. Maintain all incident reports in an incident database (For electronic reporting, the original messages will be retained. For telephonic reporting, the analyst who answered the phone will prepare a summary and enter it into the database. For each incident, the database record will include, the date and time the report was received, the person who submitted the report, the handling analyst, and the original message or a summary.).

    17. Develop a plan to acquire the data used for analysis.

    18. Create a plan (i.e., Data Acquisition Plan) that prioritizes the sources, establishing the order in which the data should be acquired.

    19. Respond to Government Forum of Incident Response Teams (GFIRST) surveys that are of an incidental or routine administrative nature.

    20. Not respond to GFIRST surveys inquiring as to the status of Treasury systems, whether certain remediation actions have taken place, future security budget plans, and the like.

    21. Participate in an memorandum of agreement/understanding (MOA/MOU) with the Situation Awareness Management Center (SAMC).

    22. Establish an MOA/MOU with the Treasury Inspector General for Tax Administration (TIGTA) to: establish formal custody transfer procedures for forensic evidence; and establish reporting procedures for incidents.

  5. In accordance with IRM 10.8.54, CSIRC shall:

    1. Establish and manage the IRS minimum firewall administration requirements.

    2. Oversee and approve all rule sets for the IRS Network perimeter firewall environments.

    3. Review and concur with IRS Information Technology organization DMZ efforts.

    4. Develop and maintain an audit plan, in accordance with IRM 10.8.3, to document what traffic will be logged.

10.8.2.2.2.4  (07-12-2010)
Situation Awareness Management Center (SAMC)

  1. In accordance with IRM 10.8.60, the Situation Awareness Management Center (SAMC) shall:

    1. Process physical security incidents.

    2. Establish a MOA/MOU with the CSIRC to establish notification procedures for when either organization discovers an incident affects the other; ensure information is recorded in the incident database for both incidents; and ensure shared staff meets the requirements of each organization.

10.8.2.2.2.5  (07-12-2010)
IRS Patch and Vulnerability Group (PVG)

  1. In accordance with IRM 10.8.50, the IRS Patch and Vulnerability Group (PVG) shall:

    1. Facilitate the identification and distribution of patches in accordance with NIST 800-40.

    2. Inventory the organization’s IT resources to determine which hardware equipment, operating systems, and software applications are used within the organization.

    3. Monitor security sources for vulnerability announcements, patch and non-patch remediations, and emerging threats that correspond to the software within the PVG’s system inventory.

    4. Prioritize the order in which the organization addresses remediating vulnerabilities.

    5. Create a database of remediations that need to be applied organization-wide.

    6. Conduct testing of patches and non-patch remediations on IT devices that use standardized configurations.

    7. Oversee vulnerability remediation.

    8. Distribute vulnerability and remediation information to local administrators.

    9. Perform automated deployment of patches to IT devices using enterprise patch management tools.

    10. Configure automatic update of applications whenever possible and appropriate.

    11. Verify vulnerability remediation through network and host vulnerability scanning.

    12. Train administrators, who apply vulnerability remediations, how to apply them appropriately.

      Note:

      This group may be an independent entity, or its duties may be performed by existing group(s) (e.g. Configuration Control Boards, Executive Steering Committees etc.).

Exhibit 10.8.2-1 
Glossary

A

Access Control - The process of granting or denying specific requests:

1) For obtaining and using information and related information processing services.

2) To enter specific physical facilities (e.g., Federal buildings, military establishments, and border crossing entrances).

Accountability - The security goal that generates the requirement for actions of an entity to be traced uniquely to that entity. This supports non-repudiation, deterrence, fault isolation, intrusion detection and prevention, and after-action recovery and legal action.

Asset - A major application, GSS, high impact program, physical plant, mission critical system, or a logically related group of systems.

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 is; or a comprehensive assessment and report on the financial condition and/or the results of performance of a government entity, program or related activity.

Authentication - Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.

Availability - The ability to access a specific resource within a specific time frame as defined with the IT product specification. The availability of an IT system allows the accessibility and usability upon demand by an authorized entity. This state is the prevention of the unauthorized withholding of information or resources.

Awareness - Activities which seek to focus attention on information security or set of issues. Awareness presentations are intended to allow individuals to recognize IT security concerns and respond accordingly. Awareness relies on reaching broad audiences with attractive packaging techniques.

B, C

Campus IDRS Security Officer - The Campus IDRS Security Officer role no longer exists. In 2009, to help ensure proper separation of duties, IDRS security user and unit account administration migrated from Cybersecurity Operations to the Enterprise Operations, Operational Security Program Management Office (EOPS-OSPMO). Cybersecurity Operations will continue to perform IDRS security policy support and oversight related tasks. The IDRS Security Officer role has been replaced with two new roles: a. The IDRS Security Account Administrator performs the user and unit account administration tasks previously performed by the IDRS Security Officer. b. The IDRS Security Analyst performs the policy support and oversight tasks previously performed by the IDRS Security Officer.

Certificate - A digital representation of information which at least:

1) Identifies the certification authority issuing it.

2) Names or identifies its subscriber.

3) Contains the subscriber’s public key.

4) Identifies its operational period.

5) Is digitally signed by the certification authority issuing it.

Certification Authority (CA) - A trusted entity in a public key infrastructure (PKI) that issues and revokes certificates exacting compliance to a PKI policy.

Chief Information Officer (CIO)/Chief Technology Officer (CTO) - An agency official responsible for:

1) Providing advice and other assistance to the head of the executive agency and other senior management/executive official of the agency to ensure that IT is acquired and information resources are managed in a manner that is consistent with laws, E.O.s, directives, policies, regulations, and priorities established by the head of the agency.

2) Developing, maintaining, and facilitating the implementation of a sound and integrated IT architecture for the agency.

3) Promoting the effective and efficient design and operation of all major information management processes for the agency, including to work processes of the agency.

Confidentiality - Preserving authorized restrictions on information access and disclosure, (including means for protecting personal privacy and proprietary information) from unauthorized individuals, entities, or processes.

Contingency Plan - Management policy and procedures designed to maintain or restore business operations, including computer operations, possibly at an alternate location, in the event of emergencies, system failures, or disaster.

Countermeasures - Actions, devices, procedures, techniques, or other measures that reduce the vulnerability of an information system. Synonymous with security controls and safeguards.

D

Department - In the context of this IRM, the terms department, departments, departmental, etc. refer solely to the IRS unless there is a specific reference to Treasury. The terms "department employee(s)" and "Treasury employee(s)" also refer to the IRS.

Designated Approving Authority (DAA)/ Authorizing Official (AO) - Official with the authority to formally assume responsibility for operating an information system at an acceptable level of risk to agency operations (including mission, functions, image, or reputation), agency assets, or individuals.

Disaster Recovery Plan (DRP) - Applies to major, usually physical disruptions to service that deny access to the primary facility infrastructure for an extended period. A DRP is an information system-focused plan created and maintained by the IRS Information Technology organization or any information technology service provider designed to restore operability of the target system, application, or computer facility infrastructure at an alternate site after an emergency. The DRP may be supported by multiple information system contingency plans to address recovery of impacted individual systems once the alternate facility has been established. A DRP may support a Business Continuity Plan or Continuity of Operations plan by recovering supporting systems for mission/business processes or mission essential functions at an alternate location. The DRP only addresses information system disruptions that require relocation.

E

Education - Education level integrates all security skills and competencies of the various functional specialties into a common body of knowledge, adds a multi-disciplinary study of concepts, issues, and principles (both technological and social), and strives to produce IT security specialists and professionals capable of forward thinking vision and pro-active response.

Encryption - The conversion of data into a form, called a ciphertext, which cannot be easily understood by unauthorized people, for the purposes of security or privacy.

Enterprise Life Cycle (ELC) - The approach used to manage and implement business change and information systems initiatives.

F

Federal Information Security Management Act (FISMA) - requires agencies to integrate information security into their capital planning and enterprise architecture processes at the agency, conduct annual security reviews of all programs and systems, and report the results of those reviews to the OMB.

Form 5081 - Information System User Registration/Change Request- Used to request access to information systems and applications. The Online 5081 replaces the paper Forms 5081 with an automated, standard process. It provides automated submission, approval, re-certification, and filing of the Form 5081 on a service-wide basis. The Online 5081 Application is an Intranet and web-based application.

Form 14201 - Risk Acceptance Request - Used to request the AO make a Risk-Based Decision (RBD) to deviate from a specific requirement and not accept the risk associated with said RBD.

G, H, I

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.

Impact - The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure/modification/destruction of information or loss of information or information system confidentiality, integrity, or availability.

Incident - A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard computer security practices.

Incident Handling - The mitigation of violations of security policies and recommended practices.

Information Owner - Official with statutory or operational authority for specified information and responsibility for establishing the controls for its generation, collection, processing, dissemination, and disposal.

Information Security - The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide CIA.

Information System Owner - Official responsible for the overall procurement, development, integration, modification, or operation and maintenance of an information system.

Information System Security Officer (ISSO) - Individual assigned responsibility by the senior agency information security officer/chief information security officer, authorizing official, management official, or information system owner for ensuring the appropriate operational security posture is maintained for an information system or program.

Information Technology (IT) - Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by an executive agency. For purposes of the preceding definition, "equipment" refers to that used by the Department of the Treasury or by a contractor under a contract with the Department of the Treasury if that contractor:

a) Requires the use of such equipment.

b) Requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product. The term "information technology" includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services) and related resources.

Information System Contingency Plan (ISCP) - Established procedures created and maintained by IRS Information Technology organization and system owners for the assessment and recovery of a system following a system disruption. The ISCP provides key information needed for system recovery, including roles and responsibilities, inventory information, assessment procedures, detailed recovery procedures, and testing of a system. The ISCP differs from DR plan primarily in that the information system contingency plan procedures are developed for recovery of the system regardless of site or location. An ISCP can be activated at the system's current location or at an alternate site. In contrast, a DR plan is primarily a site-specific plan developed with procedures to move operations of one or more information systems from a damaged or uninhabitable location to a temporary alternate location. Once the DR plan has successfully transferred an information system site would then use its respective ISCO to restore, recover, and test systems, and put them in operation.

Integrity - The prevention of the unauthorized/improper modification or destruction of information; includes ensuring information non-repudiation and authenticity.

Interconnection Security Agreement (ISA) - An agreement established between the organizations that own and operate connected information systems to document the technical requirements of the interconnection. The ISA also supports a Memorandum of Understanding or Agreement (MOU/A) between the organizations.

J, K

Key Management - The activities involving the handling of cryptographic keys and other related security parameters during the entire life cycle of the keys, including their generation, storage, establishment, entry and output, and zeroization.

Key Pair - Two mathematically related keys having the properties that one key can be used to encrypt a message that can only be decrypted using the other key. Even knowing one key, it is computationally infeasible to discover the other key.

L

Least Privilege - The security objective of granting users only those accesses they need to perform their official duties.

Live Data - Live Data is primarily unmodified, non sanitized data extracted from taxpayer files which identities specific individual or corporate taxpayers. It includes taxpayer information, tax return information, and further extends to include live employee data, any other sensitive personally identifiable information (PII), and any Sensitive but Unclassified (SBU) data that is used outside of the authorized IRS production environment. Live data is another form of Sensitive but Unclassified (SBU) data. The use of live data in testing environments is limited to tax administration or other authorized IRS purposes and may be disclosed only to those individuals with a need to know.

M

Major Application - An application that requires special attention to security due to the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application. Note: All federal applications require some level of protection. Certain applications, because of the information they hold, however, require special management oversight and shall be treated as major. Adequate security for other applications shall be provided by security of the systems in which they operate.

N

Non-repudiation - Assurance that the sender of information is provided with proof of delivery and the recipient is provided with proof of the sender's identity, so neither can later deny having processed the information.

O, P

Plan of Action and Milestones (POA&M) - A document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones.

Privacy Impact Assessment (PIA) - A process for examining the risks and ramifications of using information technology to collect, maintain and disseminate information in identifiable form about members of the public and agency employees. The PIA also identifies and evaluates protections to mitigate the impact to privacy of collecting such information.

Personally Identifiable Information (PII) - Any information about an individual maintained by an agency, including:

  1. Information that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records.
    a. To Distinguish an individual is to identify an individual such as SSN and Passport Number. However, a list of credit scores without any other information concerning the individual does not distinguish the individual.
    b. To Trace an individual is to process sufficient information to make a determination about a specific aspect of an individuals activities or status, for example an audit log.

  2. Information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.
    a. Linked information is information about or related to an individual that is logically associated with other information about the individual.
    b. Linkable information is information about or related to an individual for which there is a possibility of logical association with other information about the individual .

  3. The definition of PII is not anchored to any single category of information or technology. Rather, it demands a case-by-case assessment of the specific risk that an individual can be identified.

Private Key - The secret part of an asymmetric key pair that is typically used to digitally sign or decrypt data.

Program - A program is the process of translating broadly stated mission needs into a set of operational requirements from which specific performance specifications are derived. A program consists of a functional area that supports a Treasury or IRS mission and has associated IT systems and budgetary resources. A program is an organized set of activities directed towards a common purpose, objective, goal, or understanding proposed by IRS to carry out responsibilities assigned to the organization. Examples of programs include: Compliance, Accounts Management, Submission Processing, production of U.S. currency, asset forfeiture, and bank supervision.

Public Information - This type of information may be disclosed to the public without restriction, but requires protection against erroneous manipulation or alteration. Example: public Web site.

Public Key - The public part of an asymmetric key pair that is typically used to verify signatures or encrypt data.

Public Key Infrastructure (PKI) - A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.

Q, R

Remediation - The act of correcting a vulnerability or eliminating a threat through activities such as installing a patch, adjusting configuration settings, or uninstalling a software application.

Review - Based on the Government Auditing Standards (2003), the IRS cannot perform self-audits, however, it can perform many of the audit activities in the context of reviews. The IRS reviews are primarily internal control reviews, based on definitions contained within this section, and comprised of assessments. This is a significant concept as it should reduce the amount of redundant work possible to conduct a review.

Risk - The level of impact on agency operations (including mission, functions, image, or reputation), agency assets, or individuals resulting from the operation of an information system given the potential impact of a threat and the likelihood of that threat occurring.

Risk Assessment - The process of identifying risks to agency operations (including mission, functions, image, or reputation), agency assets, or individuals by determining the probability of occurrence, the resulting impact, and additional security controls that would mitigate this impact. Part of risk management (incorporating threat and vulnerability analyses), the output of this process helps to identify appropriate controls for reducing or eliminating risk during the risk mitigation process. The risk assessment brings together important information for agency officials with regard to the protection of the information system and generates essential information required for the security plan. The periodic assessment of risk to agency assets or operations resulting from the operation of an information system is an important activity required by FISMA. (also Security Risk Assessment)

S

Safeguards - Protective measures prescribed to meet the security requirements (i.e., CIA) specified for an information system. Safeguards may include security features, management constraints, personnel security, and security of physical structures, areas, and devices.

Scanning - Sending packets or requests to another system to gain information to be used in a subsequent attack.

Security Assessment and Authorization (SA&A) - 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 requirements for the system.

Security Controls - The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the CIA of the system and its information.

Security Requirements - Requirements levied on an information system that are derived from laws, E.O.s, directives, policies, instructions, regulations, or organizational (mission) needs to ensure the CIA of the information being processed, stored, or transmitted.

Self-Assessment - A method for agency officials to determine the current status of their information security programs and, where necessary, establish a target for improvement. For a self-assessment to be effective, a risk assessment shall be conducted in conjunction with, or prior to the self-assessment. A self-assessment does not eliminate the need for a risk assessment.

Sensitive But Unclassified (SBU) Information - Any information which if lost, stolen, misused, or accessed or altered without proper authorization, may adversely affect the national interest or the conduct of federal programs (including IRS operations), or the privacy to which individuals are entitled under FOIA (5 U.S.C. 552).

Sensitive Information - Information the loss, misuse, or unauthorized access to, or modification of which could adversely affect the national interest or the conduct of Federal programs, or the privacy to which individuals are entitled under 5 U.S.C. § 552a (the Privacy Act), but has not been specifically authorized under criteria established by an E.O. or an act of Congress to be kept classified in the interest of national defense or foreign policy. Examples of such sensitive information include personal financial information and information that discloses law enforcement investigative methods. Other particular classes of information may have additional statutory limits on disclosure that require that information to also be treated as sensitive. Examples include tax information, which is protected by Section 6103 of the IRC (26 U.S.C. § 6103) and advanced procurement information, protected by the Procurement Integrity Act (41 U.S.C. § 423).

System - A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. A system normally includes hardware, software, information, data, applications, communications, and people.

System Administrator (SA) - A person who manages the technical aspects of a system.

System Development Life Cycle (SDLC) - The scope of activities associated with a system, encompassing the system’s initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal that instigates another system initiation.

System Security Plan - Formal document that provides an overview of the security requirements for the information system and describes the security controls in place or planned for meeting those requirements.

T

Technical Controls - The security controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by the information system through mechanisms contained in the hardware, software, or firmware components of the system.

Threat - Any circumstance or event with the potential to adversely impact agency operations (including mission, functions, image, or reputation), agency assets, or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.

Training - Training is more formal than "awareness," having the goal of building knowledge and skills to facilitate security in one’s job performance. The training level strives to produce relevant and needed security skills and competency by practitioners whose functional specialties are other than IT security (e.g., management, systems design, development, acquisition, auditing). Current training guidance encourages Role-Based Training.

U, V

Vulnerability - Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.

Vulnerability Assessment - Formal description and evaluation of the vulnerabilities in an information system.

Exhibit 10.8.2-2 
References

Department of Treasury

  1. TD P 85-01 Volume I, Department of Treasury Information Technology Security Program, July 2, 2013.

  2. TD P 87–04, Personal Use of Government Information Technology Resources, January 27, 2012
    The Treasury Directives above are available at: http://thegreen.treas.gov/POLICIES/Pages/default.aspx

Internal Revenue Manuals (IRMs)

  1. IRM 1.1.17, Organization and Staffing, Agency-Wide Shared Services, July 26, 2010.

  2. IRM 1.4.X series, Resource Guide For Managers.

  3. IRM 1.4.1, Resource Guide for Managers, Management Roles and Responsibilities, January 20, 2012.

  4. IRM 10.2.14, Physical Security Program, Methods of Providing Protection , September 23, 2009.

  5. IRM 10.5.1, Privacy Information Protection and Data Security (PIPDS), Policy Roles and Responsibilities, May 5, 2010.

  6. IRM 10.8.1, Information Technology (IT) Security, Policy and Guidance, May 3, 2012 .

  7. IRM 10.8.3, Audit Logging Security Standards , September 16, 2011..

  8. IRM 10.8.6, Information Technology (IT) Security, Secure Application Development, January 24, 2013.

  9. IRM 10.8.8, Information Technology (IT) Security, Live Data Protection , August 31, 2010.

  10. IRM 10.8.10, Information Technology (IT) Security, Linux and Unix Security Policy, April 5, 2013.

  11. IRM 10.8.20, Information Technology (IT) Security, Windows Security Policy, June 6, 2013.

  12. IRM 10.8.21, Information Technology (IT) Security, Database Security Policy, April 24, 2013.

  13. IRM 10.8.22, Information Technology (IT) Security, Web Server Security Policy , April 24, 2013.

  14. IRM 10.8.26, Information Technology (IT) Security, Laptop Computer Security Policy, October 03, 2012.

  15. IRM 10.8.27, Information Technology (IT) Security, Internal Revenue Service Policy On Limited Personal Use Of Government Information Technology Resources, October 2, 2012.

  16. IRM 10.8.34, Information Technology (IT) Security, IDRS Security Controls, October 14, 2011.

  17. IRM 10.8.40, Information Technology (IT) Security, Wireless Security Policy, October 5, 2012.

  18. IRM 10.8.50, Information Technology (IT) Security, Service-wide Security Patch Management, August 15, 2012.

  19. IRM 10.8.54, Information Technology (IT) Security, Minimum Firewall Administration Requirements, December 20, 2012.

  20. IRM 10.8.60, Information Technology (IT) Security, Disaster Recovery Policy and Guidance, October 4, 2012.

  21. IRM 10.9.1, National Security Information, National Security Information, August 14, 2012.

    The IRS' Office of Service-wide Policy, Directives and Electronic Research (SPDER), in partnership with LEXIS-NEXIS, has made all IRMs available to all IRS employees. IRS IRMs are available at: http://irm.web.irs.gov . IRS Information Technology Cybersecurity organization IRMs are available at: http://it.web.irs.gov/Cybersecurity/

NIST

  1. NIST SP 800-16, Information Technology Security Training Requirements: A Role- and Performance-Based Model, April 1998.

  2. NIST SP 800-37 Rev. 1, Guide for the Security Certification and Accreditation of Federal Information Systems, February 2010.

  3. NIST SP 800-40 Ver 2.0 Creating a Patch and Vulnerability Management Program , November 2005.

  4. NIST SP 800 - 53 Rev. 4, Security and Privacy Controls for Federal Information Systems and Organizations, April 30, 2013.

  5. NIST SP 800-53A, Guide for Assessing the Security Controls in Federal Information Systems, June 2010.

  6. NIST SP 800-57 Part 1, Recommendation for Key Management – Part 1: General (Revision 3) July 2012.

  7. NIST SP 800-100, Information Security Handbook: A Guide for Managers, October 2006.
    Information regarding the NIST publications noted above is available on the NIST web site:http://csrc.nist.gov

Other References

  1. FISMA requirements (see http://csrc.nist.gov/sec-cert/).

  2. IRS FISMA activities can be found at the IRS Information Technology Cybersecurity organization web site, http://it.web.irs.gov/Cybersecurity/.

  3. Privacy Act of 1974.

  4. OMB Memorandum for Chief Acquisition Officers - Revisions to the Federal Acquisition Certification for Contracting Officer’s Representatives (FAC-COR), Sep 6, 2011.

  5. OMB Circular No. A-130, Management of Federal Information Resources, November 28, 2000

  6. Public Law 105-35, Taxpayer Browsing Protection Act of 1997

  7. Consolidated Appropriate Act, 2005 (H.R. 4818)

  8. Code of Federal Regulations (CFR), Title 5 - Administrative Personnel


More Internal Revenue Manual