10.8.2  IT Security Roles and Responsibilities (Cont. 1)

10.8.2.2 
Roles and Responsibilities

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  (09-05-2012)
IRS Information Technology Cybersecurity Organization

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

    1. Develop security controls for systems and applications;

    2. Conduct annual testing of the systems and applications;

    3. Test and validate the effectiveness of corrective actions;

    4. Ensure IT contingency planning and DR requirements are addressed for all applications and systems owned by IRS Information Technology Cybersecurity organization;

    5. Mitigate technical vulnerabilities and validate fixes;

    6. Implement corrective actions to mitigate weaknesses assigned to IRS Information Technology Cybersecurity;

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

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

  2. For Disaster Recovery (DR) and IT Contingency Planning, 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 IRS Information Technology Cybersecurity 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; and

    12. Refer to IRM 10.8.60, Information Technology (IT) Disaster Recovery Policy and Guidelines for additional information on IT Disaster Recovery roles & responsibilities.

  3. In accordance with IRM 10.8.3, Audit Logging Security Standards, 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; and

    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. 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 Information Technology Asset Management System (ITAMS) ticket needing CSIRC’s attention;

    3. Notify CSIRC for a user’s problem that originated with the Help Desk Operations; and

    4. Report suspicious activity or incidents.

  5. 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; and

    2. IRS Information Technology organization shall perform containment activities.

10.8.2.2.2.2  (09-05-2012)
IRS Information Technology User and Network Services Organization (UNS)

  1. In accordance with IRM 10.8.54, Minimum Firewall Administration Requirements, 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 polices 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; and

    5. Securing maintenance contracts.

  5. 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; and

    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, Wireless Security, 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, Service-wide Security Patch Management, 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 e-mail 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; and

    15. Send approved advisories as e-mail messages to the PVG members. The e-mail 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 Information Technology (IT) Security Policy and Guidance, 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, and
      •Reporting.

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

    5. Actively and continuously monitor IT resources, to include firewalls, 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 (the 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); and

    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 10.8.54 Minimum Firewall Administration Requirements, the 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; and

    4. Develop and maintain an audit plan 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.54, Minimum Firewall Administration Requirements, the Situation Awareness Management Center (SAMC) shall:

    1. Process physical security incidents; and

    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, Service-wide Security Patch Management, 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; and

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

10.8.2.2.2.6  (09-05-2012)
Incident Commander

  1. In accordance with IRM 10.8.1, Information Technology (IT) Security Policy and Guidance, each incident is assigned to an Incident Commander who serves as the primary contact and managing authority for the incident. The Incident Commander shall:

    1. Assign incident response duties to IRS Information Technology Cybersecurity organization per the MOA/MOU;

    2. Ensure that all incident related communications and reports are properly documented;

    3. Facilitate information sharing between organizations with a need to know;

    4. Escalate actions as necessary;

    5. In conjunction with the business owner of the system and data and possibly law enforcement, make decisions on whether to eradicate the security vulnerability, preserve the evidence for potential prosecution, or both; and

    6. The Incident Commander shall validate the CSIRC authority when requested.

10.8.2.2.2.7  (09-05-2012)
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 training;

    7. Employees with significant security responsibilities shall receive, at least annually, specialized security awareness training specific to their security role and responsibilities;

    8. Thoroughly read and abide by the Rules of Behavior for the systems (consult the Online (OL) Form 5081 procedures), as well as associated policies and procedures to which personnel are granted access;

    9. 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);

    10. Not access sensitive/classified IT systems until they have received the inbrief for the appropriate clearance for the IT system;

    11. Sign a Form 11370, Certification of Annual UNAX Awareness Briefing. This certification/form indicates that the employee has completed the required UNAX training;

    12. 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;

    13. 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);

    14. 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 for further guidance);

    15. Receive Security (ATE/SATE). Refer to IRM 10.8.1 for detailed training requirements; and

    16. Escort visitors of IRS facilities.

  3. Adhere to IRM 10.8.1 to:

    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; and

    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, Limited Personal Use of Government Information Technology Resources, 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 Conduct 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. 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. Use IRS e-mail accounts for performance of official duties;

    10. Not automatically forward e-mail messages to non-IRS accounts; and

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

10.8.2.2.2.8  (07-12-2010)
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. 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 diskettes, 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;

    18. Complete Unauthorized Access (UNAX) training when required and sign a Form 11370, Certification of Annual UNAX Awareness Briefing indicating completed training; and

    19. 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. Adhere to IRM 10.8.1 to:

    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; and

    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, Laptop Computer Security.

  5. In accordance with Treasury’s TDP 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 e-mail accounts for performance of official duties;

    10. Not automatically forward e-mail messages to non-IRS accounts; and

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

10.8.2.2.2.9  (09-05-2012)
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. DBAs shall have the least level of elevated privileges required to perform DBA-related duties and shall not have system administration 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; and

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

10.8.2.2.2.10  (07-12-2010)
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 (Revised) (dated May 2006), 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; and

    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.2.11  (07-12-2010)
Network Administrator (NA)

  1. Network Administrators (NAs) shall be responsible for the day-to-day administration of the network device.

  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, Audit Logging Security Standards 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 implementing processes, changes and improvements to programs, procedures and network devices;

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

    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, Service-wide Security Patch Management for further information concerning security patch management.

10.8.2.2.2.12  (07-12-2010)
Program Developer/Programmer

  1. Program Developers/Programmers shall be responsible for the development, test and administration 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, Secure Application Development;

    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.2.13  (09-05-2012)
Web Developer

  1. In accordance with IRM 10.8.22, Web Server Security Policy, 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; and

    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.2.14  (09-05-2012)
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.

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

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

    3. Start up and shut down the system;

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

    5. Monitor system/user access for performance concerns; and

    6. Perform 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 Form 5081 process for user administration requests, while routing the request to the appropriate non-SA (e.g., EAA 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.2.15  (09-05-2012)
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 Enterprise Account Administration (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; and

    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; and

    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; and

    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. 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;

    2. Ensuring that the requirements of the IRM 10.8.1 and 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; and

    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 ,Basic UNIX Security Requirements (BUSR), the SecSpec (also known as Security Admins Group) 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 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; and

    4. Not have operating System Administrator privileges.

  10. In accordance with IRM 10.8.20, Windows Security Policy, the SecSpec (also known as Security Admins Group) 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; and

    4. Not have operating System Administrator privileges.

  11. In accordance with IRM 10.8.22, Web Server Security Policy, 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; and

    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.2.16  (09-05-2012)
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 configuring their access controls to provide the users necessary access with least privilege, as defined for each user in the Form 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, Audit Logging Security Standards 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; and

    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 on each specialist's Form 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 AOs.

  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 IT Contingency Plan and DR Plan development and accuracy.

10.8.2.2.2.17  (07-12-2010)
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; and

    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.2.18  (09-05-2012)
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. He/she shall support IT Contingency Plan and DR Plan development, accuracy, documentation, and implementation efforts for their system(s).

10.8.2.2.2.19  (07-12-2010)
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 Form 5081 process.

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

10.8.2.2.2.20  (07-12-2010)
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; and

    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.2.21  (09-05-2012)
IDRS Security Officer

  1. The IDRS Security Officer shall be a non-bargaining unit employee who is a member of the IRS Information Technology Cybersecurity staff and performs tasks relating to the security of IDRS and IRS Information Technology 22 Security and Communication System (SACS).

  2. The IDRS Security Officer has overall responsibility for the implementation of all IDRS security matters that are relative to users accessing his/her campus IDRS database.

  3. In accordance with IRM 10.8.34, Integrated Data Retrieval System (IDRS) Security Handbook, the IDRS Security Officer shall:

    1. Monitor the administration of the IDRS security program in the IRS campus, and other offices that have access to their IDRS database to ensure that the program is properly implemented and maintained;

    2. Advise management on matters relating to IDRS security;

    3. Train and work with the managers and Unit Security Representatives (USRs) to maintain the desired level of IDRS security;

    4. Conduct training sessions, at least annually, for the USRs, specifically to cover security awareness and the technical aspects of IDRS;

    5. Perform activities throughout the year to promote and maintain a continuing awareness of security;

    6. Confirm that daily, weekly, monthly, and quarterly IDRS security reports are properly loaded into IDRS Online Reports Services (IORS) application and notify the IDRS Security National Program Office of any known instances when IDRS reports are not loaded within a 24 hour period or have data discrepancies;

    7. Maintain, have access to, or be able to acquire and explain how to complete and submit security related documentation requests which include Online 5081 Application, Form 9936 Request for Audit Trail Extract, Form 9937 IDRS Unit Request, Form 13230 IDRS Security Personnel Designation, and all IDRS activities requiring documentation. Require that USRs and managers use IORS to submit Form 9937 and the other forms as they become available on IORS to the IDRS Security Staffs for processing;

    8. Assist managers and business division security personnel in getting access to and using the IDRS Online Reports Services (IORS) and the IDRS Unit and USR Database (IUUD);

    9. Review all daily IDRS security reports that report security transactions and violations to identify items that need additional investigation and complete certification requirements in IORS in a timely manner for all security reports requiring IDRS Security Officer action and certification;

    10. Periodically review, in an oversight capacity, the various IDRS security reports provided to USRs and managers for trends; for compliance with IDRS security rules, and to ensure that USRs and managers are adequately reviewing reports in a timely and appropriate manner;

    11. Review the IDRS Online Reports Services (IORS) application internal reports to determine whether all IDRS units have USRs and managers who are designated as primary recipients who are responsible for reviewing IDRS Security reports in a timely manner, certifying the reports, and taking the appropriate action, as needed;

    12. Have access to all security reports, manuals, and handbooks pertaining to IDRS;

    13. Distribute and document the distribution of this IRM and other related material to the appropriate personnel;

    14. Ensure IDRS bulletins, approved waivers, local forms and written procedures are sent to all USRs to keep them apprised of IDRS activities;

    15. Periodically call upon their alternate(s) for assistance when the workload demands;

    16. Ensure that USRs are monitoring IDRS user compliance with SINOF requirements;

    17. Ensure that USRs have documented the appropriateness of all accesses to taxpayer accounts identified in the weekly IDRS security reports;

    18. Advise USRs about the requirement for managers to discuss with users the need to properly sign-off IDRS when users are identified as having 15 or more automatic sign-offs per month;

    19. Advise USRs about requirements to have users sign-off IDRS in the event of an emergency office closing;

    20. Request waivers for requirements in this policy for any actions or activities that are not in compliance;

    21. Maintain copies of all approved waivers, written local procedures, and local forms that are used to administer the IDRS security program; and

    22. Confirm that employees designated as Unit Security Representative or IORS Primary Recipient are non-bargaining employees.

  4. For additional related responsibilities, refer to IRM 10.8.34, Integrated Data Retrieval System (IDRS) Security Handbook.

10.8.2.2.2.22  (09-05-2012)
IDRS Security User Administrator

  1. The IDRS Security User Administrator shall be a non-bargaining unit employee who is a member of the IRS Information Technology EOPS-OSPMO staff and performs tasks relating security administration of IDRS user and unit accounts.

  2. In accordance with IRM 10.8.34, Integrated Data Retrieval System (IDRS) Security Handbook, the IDRS Security User Administrator shall:

    1. Add or delete employee access to IDRS; IDRS Security User Administrators are responsible for ensuring user accounts are established in the proper unit, Office Identifier (OI), and organization code range;

    2. Develop or update the Maximum Profile Authorization File (MPAF) and the Unit Command Code Profile (UCCP) based on signed requests from the USRs;

    3. Coordinate with USRs and unit/group managers to create new IDRS units that fall under the unit/group managers’ jurisdictions; IDRS Security User Administrators are responsible for ensuring the Office Identifier (OI) and Organization code for the new unit are consistent with the unit number ranges specified in IRM 10.8.34;

    4. Assign temporary passwords to IDRS users as requested or when adding users to IDRS;

    5. Add or delete terminals to IDRS (in coordination with the host computing center);

    6. Periodically review and update all IDRS user information in the Master Register of Active IDRS Users report for completeness and accuracy. This includes user Standard Employee Identifier (SEID), telephone numbers, and background investigation status;

    7. Maintain the IDRS Unit and USR Database (IUUD) to include a current list of USRs, alternate USRs, Terminal Security Administrators (TSAs) and managers for all IDRS units. Ensure the IUUD includes the name, address, and phone number for all persons listed. Ensure the IUUD includes the complete TIMIS description for the group or team whose employees are included in the IDRS unit number;

    8. Maintain, have access to, and explain how to complete and submit security related documentation requests which include Online 5081 Application and Form 9937 IDRS Unit Request;

    9. Add or delete employee access to the IDRS Online Reports Services (IORS); command code REPTS is used for IORS access; ensure that employees designated as IORS Primary Recipient are non-bargaining employees before adding REPTS to their profile;

    10. Review any certify IDRS security reports requiring IDRS Security User Administrator action;

    11. Lock any unit that has active IDRS users, but no primary recipient to review/certify IDRS security reports;

    12. Add or delete security command codes to user profiles; and

    13. Ensure that employees designated as Unit Security Representative have received the required training and are non-bargaining employees before adding security command codes to their profile.

  3. The IDRS Security User 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; and

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

  4. For additional related responsibilities, refer to IRM 10.8.34, Integrated Data Retrieval System (IDRS) Security Handbook.

10.8.2.2.2.23  (12-03-2010)
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 audits, whose software package may not be compatible with each other thus they cannot be loaded onto a system at the same time.

10.8.2.2.2.24  (09-05-2012)
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 own 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 Campus;

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

    7. Provide both orally 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.2.25  (12-03-2010)
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; and

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

10.8.2.2.2.26  (12-03-2010)
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; and

    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 the priority of implementing security safeguards.

10.8.2.2.2.27  (12-03-2010)
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.2.28  (04-29-2011)
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); and

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

10.8.2.2.2.29  (04-29-2011)
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; and

    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.3  (09-05-2012)
Risk Acceptance and Risk Based Decisions

  1. An exception to this policy requires that the Authorizing Official (AO) make a Risk Based Decision. Risk Based Decision requests shall be submitted in accordance with IRM 10.8.1 and use Form 14201, as described in Request for Risk Acceptance and Risk Based Decision Standard Operating Procedures (SOPs). Refer to IRM 10.8.1 for additional information.

  2. Titles of organizations or job titles of staff that differ from this IRM do not require a Risk Based Decision.

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

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; and

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; and

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) - A document created and maintained by the IRS Information Technology organization or any information technology service provider that defines the resources, roles, responsibilities, actions, tasks, and the steps required, down to a keystroke level, to restore an IT system to its full operational status at the current or alternate facility after a disruption.

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 - Virtually every customer within IRS must utilize the IRS Form 5081, Information System User Registration/Change Request, 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.

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, or

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) - Documents created and maintained by IRS Information Technology organization and system owners that define the resources, roles, responsibilities, and procedures for recovering IT applications and General Support Systems (GSS) after a disruption.

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 - An analysis of how information is handled:

1) to ensure handling conforms to applicable legal, regulatory, and policy requirements regarding privacy;

2) to determine the risks and effects of collecting, maintaining, and disseminating information in identifiable form in an electronic information system; and

3) to examine and evaluate protections and alternative processes for handling information to mitigate potential privacy risks.

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 that requires protection due to the risk and magnitude of loss or harm to the IRS or the privacy to which individuals are entitled under 5 U.S.C. § 552a (the Privacy Act), which could result from inadvertent or deliberate disclosure, alteration, or destruction.

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, Department of Treasury Information Technology Security Program, Volume I and II Handbook, June 8, 2011.
    The TDs above are available at:http://treas.gov/regs.

Internal Revenue Manuals (IRMs)

  1. IRM 10.8.1, IT Security Policy and Guidance, November 25, 2011.

  2. IRM 10.8.2, IT Security Roles and Responsibilities, April 29, 2011.
    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://spder.web.irs.gov/IRMOnline/irm.htm. IRS Information Technology Cybersecurity organization IRMs are available at:http://mits.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. 3, Recommended Security Controls for Federal Information Systems, August 2009.

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

  6. NIST SP 800-57, Recommendation for Key Management – Part 1: General (Revised) March 2007.

  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://mits.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


More Internal Revenue Manual