47
Computer System Security
Section 9.0
Publication 1075 (October 2014)
Page 98
The service and deployment model used in a cloud computing environment will
determine the responsibility for security controls implementation between the agency
and the cloud provider for the protection of FTI that is stored or processed in the cloud
environment. The delineation of security control responsibility is heavily dependent on
the service and deployment models of the solution the agency is adopting. For example,
if the solution is an SaaS email solution, the agency may be responsible for a small
subset of security control responsibilities. If the agency is deploying its own applications
to a PaaS or IaaS solution, it will have greater responsibility for securing the application
layer and potentially the platform and middleware.
Requirements
The following mandatory controls are applicable for all cloud service and deployment
models. However, as stated earlier, depending on the deployment model, compensating
controls can be accepted in place of the mandatory requirements provided that those
compensating controls afford the same level of protection as mandatory controls for
safeguarding FTI. Potential compensating controls will be evaluated by the Office of
Safeguards, as part of the cloud computing notification (see first requirement).
To use a cloud computing model to receive, process, store, or transmit FTI, the agency
must be in compliance with all requirements in this publication. The following mandatory
requirements are in effect for introducing FTI to a cloud environment:
a. Notification Requirement: The agency must notify the Office of Safeguards at
least 45 days prior to transmitting FTI into a cloud environment.
b. Data Isolation: Software, data, and services that receive, process, store, or
transmit FTI must be isolated within the cloud environment so that other cloud
customers sharing physical or virtual space cannot access other customer data
or applications.
c. SLA: The agency must establish security policies and procedures based on IRS
Publication 1075 for how FTI is stored, handled, and accessed inside the cloud
through a legally binding contract or SLA with its third-party cloud provider.
d. Data Encryption in Transit: FTI must be encrypted in transit within the cloud
environment. All mechanisms used to encrypt FTI must be FIPS 140-2 compliant,
and operate using the FIPS 140-2 compliant module. This requirement must be
included in the SLA.
e. Data Encryption at Rest: FTI may need to be encrypted while at rest in the cloud,
depending upon the security protocols inherent in the cloud. If the cloud
environment cannot appropriately isolate FTI, encryption is a potential
compensating control. All mechanisms used to encrypt FTI must be FIPS 140-2
compliant and operate using the FIPS 140-2 compliant module. This requirement
must be included in the SLA, if applicable.
f. Persistence of Data in Relieved Assets: Storage devices where FTI has resided
must be securely sanitized or destroyed using methods acceptable by NSA and
Central Security Service (CSS). This requirement must be included in the SLA.
g. Risk Assessment: The agency must conduct an annual assessment of the
security controls in place on all information systems used for receiving,
43
Computer System Security
Section 9.0
Publication 1075 (October 2014)
Page 99
processing, storing, or transmitting FTI. For the annual assessment immediately
prior to implementation of the cloud environment and each annual risk
assessment (or update to an existing risk assessment) thereafter, the agency
must include the cloud environment. The Office of Safeguards will evaluate the
risk assessment as part of the notification requirement in Requirement A.
h. Security Control Implementation: Customer-defined security controls must be
identified, documented, and implemented. The customer-defined security
controls, as implemented, must comply with requirements in this publication.
Additional cloud computing security requirements are available on the Office of
Safeguards website.
9.4.2 Data Warehouse
The concept of data warehousing consists of a collection of multi-dimensional integrated
databases that are used to provide accessible information to clients or end users. The
data can be manipulated through different categories or dimensions to facilitate
analyzing data in relational databases. The result can provide the client or end user with
an enterprise view or snapshot of the information.
Security requirements apply to data warehousing environments, as well as to typical
networked environments.
Section 5.2 and Exhibit 10, Data Warehouse Security Requirements, provide unique
requirements for this environment.
Additional data warehouse security requirements are available on the Office of
Safeguards website.
9.4.3 Email Communications
If FTI is prohibited from inclusion within emails or email attachments, a policy must be
written and distributed.
If FTI is allowed to be included within emails or email attachments, the agency must
only transmit FTI to an authorized recipient and must adhere to the following
requirements:
a. Policies and procedures must be implemented to ensure FTI is properly
protected and secured when being transmitted via email;
b. Mail servers and clients must be securely configured according to the
requirements within this publication to protect the confidentially of FTI transmitted
in the email system;
c. The network infrastructure must be securely configured according to the
requirements within this publication to block unauthorized traffic, limit security
vulnerabilities, and provide an additional security layer to an agency
’
s mail
servers and clients;
50
Computer System Security
Section 9.0
Publication 1075 (October 2014)
Page 100
d. Emails that contain FTI should be properly labeled (e.g., email subject contains
“
FTI
”
) to ensure that the recipient is aware that the message content contains FTI;
e. Audit logging must be implemented to properly track all email that contains FTI;
f. Email transmissions that contain FTI must be encrypted using a FIPS 140-2
validated mechanism; and
g. Malware protection must be implemented at one or more points within the email
delivery process to protect against viruses, worms, and other forms of malware.
9.4.4 Fax Equipment
If FTI is prohibited from inclusion within fax communications, a policy must be written
and distributed.
If FTI is allowed to be included within fax communications, the agency must only
transmit FTI to an authorized recipient and must adhere to the following requirements:
a. Have a trusted staff member at both the sending and receiving fax machines;
b. Accurately maintain broadcast lists and other preset numbers of frequent
recipients of FTI;
c. Place fax machines in a secured area; and
d. Include a cover sheet on fax transmissions that explicitly provides guidance to
the recipient, which includes:
1. A notification of the sensitivity of the data and the need for protection; and
2. A notice to unintended recipients to telephone the sender
—
collect, if
necessary
—
to report the disclosure and confirm destruction of the
information.
9.4.5 Integrated Voice Response Systems
To use an Integrated Voice Response (IVR) system that provides FTI over the
telephone to a customer, the agency must meet the following requirements:
a. The LAN segment where the IVR system resides is firewalled to prevent direct
access from the Internet to the IVR system;
b. The operating system and associated software for each system within the
architecture that receives, processes, stores, or transmits FTI to an external
customer through the IVR is hardened in accordance with the requirements in
this publication and is subject to frequent vulnerability testing;
c. Independent security testing must be conducted on the IVR system prior to
implementation; and
d. Access to FTI via the IVR system requires a strong identity verification process.
The authentication must use a minimum of two pieces of information although
more than two are recommended to verify the identity. One of the authentication
elements must be a shared secret only known to the parties involved and issued
by the agency directly to the customer. Examples of shared secrets include a
unique username, PIN number, password, or pass phrase issued by the agency
44
Computer System Security
Section 9.0
Publication 1075 (October 2014)
Page 101
to the customer through a secure mechanism. Case number does not meet the
standard as a shared secret because that case number is likely shown on all
documents the customer receives and does not provide assurance that it is only
known to the parties involved in the communication.
Additional IVR security requirements are available on the Office of Safeguards website.
9.4.6 Live Data Testing
The use of live FTI in test environments should generally be avoided and is not
authorized unless specifically approved by the Office of Safeguards through the
submission of a Data Testing Request (DTR) form.
The IRS defines live data as primarily unmodified, non-sanitized data extracted from
taxpayer files that identifies specific individual or corporate taxpayers and includes
taxpayer information or tax return information. 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.
Any systems within pre-production testing environments ideally will be configured
according to requirements in this publication. However the Office of Safeguards
understands most agencies may not be able to fully implement all Publication 1075
requirements in a test environment.
Agencies wishing to use live FTI data in pre-production must submit a DTR to the IRS
Office of Safeguards for authority to use live data for testing, providing a detailed
explanation of the safeguards in place to protect the data and the necessity for using
live data during testing.
Need and Use Justification statements should be revised to cover this use of IRS data,
if not already addressed. State taxing agencies should check their statements
(agreements) to see if
“
testing purposes
”
is covered.
Testing efforts that use live FTI data primarily fall into two categories: one-time testing
and ongoing testing.
An example of a one-time testing use of live FTI data would be for system testing that is
done prior to a new system implementation and, once testing has validated that the data
will work properly, the live FTI data is not required to continue to remain in the test
environment. For one-time testing efforts, the Office of Safeguards requires the FTI to
be deleted from systems and databases upon completion of testing efforts and that the
hard drive of the test systems be cleared electronically prior to repurposing the system
for other state agency testing efforts.
Duration for ongoing test activities will be agreed upon as part of the live data request
process. Some examples of ongoing testing efforts include:
49
Computer System Security
Section 9.0
Publication 1075 (October 2014)
Page 102
a. Testing of extract, transform, load (ETL) process to validate federal data load to a
database;
b. Application testing of income modeling that requires data match between the
entire population of state and federal returns, where building a set of dummy data
is not feasible; and
c. Testing audit selection queries that run against the entire population of federal
returns to identify potential state non-filers, where building a set of dummy data
that would correspond to actual state returns is not feasible.
9.4.7 Media Sanitization
The type of sanitization performed depends on whether or not the media:
a. Is to be reused by the agency for continued use with FTI; or
b. Will be leaving agency control.
If the media will be reused by the agency for the same purpose of storing FTI and will
not be leaving organization control, then clearing is a sufficient method of sanitization. If
the media will be reused and repurposed for a non-FTI function or will be leaving
organization control (i.e., media being exchanged for warranty, cost rebate, or other
purposes and where the specific media will not be returned to the agency), then purging
should be selected as the sanitization method. If the media will not be reused at all, then
destroying is the method for media sanitization.
The following media sanitization requirements are required:
a. The requirements are applicable for media used in a
“
pre-production
”
or
“
test
”
environments.
b. The technique for clearing, purging, and destroying media depends on the type
of media being sanitized.
c. A representative sampling of media must be tested after sanitization has been
completed.
d. Media sanitization should be witnessed or verified by an agency employee.
e. Media sanitization requirements are the same, regardless of where the
information system media is located. However, the party responsible for each
step of the sanitization process may differ.
Additional media sanitization requirements are available on the Office of Safeguards
website.
9.4.8 Mobile Devices
Background
Mobile devices provide several unique security and management challenges when used
to access corporate resources, including sensitive data. Mobile devices can store vast
amounts of data and, by default, security options are not enabled. This leaves the
devices vulnerable to allowing an unauthorized person to gain access to the information
51
Computer System Security
Section 9.0
Publication 1075 (October 2014)
Page 103
stored on them or accessed through them. In addition, due to the portable nature of
mobile devices, they are susceptible to loss or theft. Another challenge to maintaining
security of mobile devices is effectively tracking mobile device inventory. Bring your own
device (BYOD) presents additional security and privacy challenges, as it may not be
possible to fully manage security of personally owned devices. These unique challenges
highlight the need to increase the security posture of mobile devices to ensure the
protection of FTI that may be stored on or accessed from a mobile device.
Requirements
To use FTI in a mobile device environment, including BYOD, the agency must meet the
following mandatory requirements:
a. Mobile device management controls must be in place that include security
policies and procedures, inventory, and standardized security configurations for
all devices;
b. An annual risk assessment must be conducted of the security controls in place
on all devices in the mobile environment used for receiving, processing, storing,
or transmitting FTI;
c. Protection mechanisms must be in place in case a mobile device is lost or
stolen
—
all data stored on the device must be encrypted, including internal
storage and removable media storage, such as Micro Secure Digital (SD) cards;
d. All data communication with the agency
’
s internal network must be encrypted
using a cryptographic module that is FIPS 140-2 compliant;
e. The agency must control end user ability to download only authorized
applications to the device and must limit the accessibility to FTI by applications to
only authorized applications;
f. All mobile device management servers that receive, process, store, or transmit
FTI must be hardened in accordance with requirements in this publication;
g. A centralized mobile device management solution must be used to authenticate
agency-issued and personally owned mobile devices prior to allowing access to
the internal network;
h. Security events must be logged for all mobile devices and the mobile device
management server;
i. The agency must disable wireless personal area networks that allow a mobile
device to connect to a computer via Bluetooth or near field communication (NFC)
for data synchronization and storage;
j. Access to hardware, such as the digital camera, global positioning system
(GPS), and universal serial bus (USB) interface, must be disabled to the extent
possible; and
k. Disposal of all mobile device component hardware follows media sanitization and
disposal procedures (see Section 9.3.10.6, Media Sanitization (MP-6), and
Section 9.4.7, Media Sanitization).
See Section 9.3.1.14, Access Control for Mobile Devices (AC-19), and Section 9.4.8,
Mobile Devices. Additional mobile device security requirements are also available on
the Office of Safeguards website.
49
Computer System Security
Section 9.0
Publication 1075 (October 2014)
Page 104
9.4.9 Multi-Functional Devices
To use FTI in a multi-functional device (MFD), the agency must meet the following
requirements:
a. The agency should have a current security policy in place for secure
configuration and operation of the MFD;
b. Least functionality controls that must be in place that include disabling all
unneeded network protocols, services, and assigning a dedicated static IP
address to the MFD;
c. Strong security controls should be incorporated into the MFD
’
s management and
administration;
d. MFD access enforcement controls must be configured correctly, including access
controls for file shares, administrator and non-administrator privileges, and
document retention functions;
e. The MFD should be locked with a mechanism to prevent physical access to the
hard disk;
f. The MFD firmware should be up to date with the most current firmware available
and should be currently supported by the vendor;
g. The MFD and its print spoolers have auditing enabled, including auditing of user
access and fax logs (if fax is enabled), and audit logs should be collected and
reviewed by a security administrator;
h. All FTI data in transit should be encrypted when moving across a WAN and
within the LAN; and
i. Disposal of all MFD hardware follows media sanitization and disposal procedure
requirements (see Section 9.3.10.6, Media Sanitization (MP-6), and Section
9.4.7, Media Sanitization).
9.4.10 Network Protections
Agencies must implement boundary protection devices throughout their system
architecture, including routers, firewalls, switches, and intrusion detection systems.
Any publicly accessible servers used in the receipt, process, transmission, or storage of
FTI must be placed into an enclave.
Network address translation (NAT) must be implemented at the public traffic
demarcation point on the network. If NAT is not implemented at the agency
’
s boundary
firewall or router, then it must be implemented on each firewall or router that protects
network segments that contain infrastructure components which receive, process, store,
or transmit FTI.
The agency
’
s managed interfaces employing boundary protection must deny network
traffic by default and allow network traffic by exception (e.g., deny all, permit by
exception). All remote traffic must migrate through a managed interface. Firewalls shall
be configured to prohibit any transmission control protocol (TCP) or user datagram
44
Computer System Security
Section 9.0
Publication 1075 (October 2014)
Page 105
protocol service or other protocol/service that is not explicitly permitted (i.e., deny by
default).
Inbound services shall be prohibited, unless a valid business case can establish their
necessity.
See Section 9.3.16.5, Boundary Protection (SC-7). Additional network protection
requirements are available on the Office of Safeguards website.
9.4.11 Storage Area Networks
Background
A storage area network (SAN) is a network whose purpose is to transfer data among
information systems and the storage elements in high speed. SANs achieve economy of
scale by eliminating the need to manage storage from multiple vendors and platforms.
The typical components of a SAN can be broken down into the host layer, the fabric
layer, and the storage layer that comprise the networking infrastructure, management
devices that organize connection, storage devices/elements, and client computer
systems. The storage layer, where FTI resides, comprises physical disk drives, disk
arrays, tape libraries, and other storage media.
SAN components that are most vulnerable to attack include connection points between
servers, management devices, and IP-based devices. The fundamental issues are that
most SAN protocols do not require device authentication and that it is relatively simple
to join the SAN fabric with a spoofing and session hijacking technique.
Requirements
To use FTI in a SAN environment, the agency must meet the following mandatory
requirements:
a. FTI must be segregated from other agency data within the SAN environment.
b. Access controls must be implemented and strictly enforced for all SAN
components to limit access to disks containing FTI to authorized users.
c. Fibre channel devices must be configured to authenticate other devices with
which they communicate in the SAN and authenticate administrator connections.
d. FTI must be encrypted while in transit within the SAN environment. SAN
management traffic must also be encrypted for SAN components.
e. SAN components must be physically protected in accordance with the minimum
protection standards for physical security described in Section 4.0, Secure
Storage
—
IRC 6103(p)(4)(B).
f. All components of the SAN that receive, process, store, or transmit FTI must be
hardened in accordance with the requirements in this publication (see SAN
SCSEM available on the Office of Safeguards website).
g. SAN components must maintain an audit trail and review it on a regular basis to
track access to FTI in the SAN environment.
43
Computer System Security
Section 9.0
Publication 1075 (October 2014)
Page 106
Additional SAN security requirements are available on the Office of Safeguards website.
9.4.12 System Component Inventory
The agency must maintain a current inventory of information systems that receive,
process, store, or transmit FTI in both production and pre-production environments.
Updates to the inventory should be a critical step when implementing installations,
removals, and updates to the information system. The inventory should accurately
reflect and be consistent with the security domain of the current information system to
enable the detection of unauthorized access to FTI within production and pre-production
environments.
The IRS does not mandate the particular details or a specific format required to capture
the inventory of systems with FTI. However, as part of the on-site safeguard review, the
IRS will evaluate the agency
’
s inventory to provide a level of assurance that the
inventory is comprehensive of all systems that receive, process, store, or transmit FTI in
production and pre-production environments.
Additional system component inventory guidance is available on the Office of
Safeguards website.
9.4.13 Virtual Desktop Infrastructure
Background
A virtual desktop infrastructure (VDI) provides users access to enterprise resources,
including a virtual desktop from locations both internal to and external to the agency
’
s
networks. In a VDI environment, a user can access FTI by connecting to a virtual
workstation via a vendor-specific agent, connection client, or through an Internet
browser from practically any mobile device with Internet access.
This requirement is applicable to VDI environments in which both agency-owned and
non-agency-owned equipment may be used as the client for the virtual desktop.
Additional security requirements apply to an agency that is approved by IRS to use non-
agency-owned equipment to access FTI through a VDI environment. The agency must
demonstrate that despite the operational location of the client, FTI remains subject to
the safeguard requirements and the highest level of attainable security.
Requirements
To use VDI that provides FTI to a customer, the agency must meet the following
mandatory requirements to lower the residual risk of the potential weaknesses identified
in the previous section:
a. VDI components should be segregated so that boundary protections can be
implemented and access controls are granulized;
Documents you may be interested
Documents you may be interested
