Purpose <\/p>\n
To define in simple terms the encryption requirements of Publication 1075 (NIST controls, FIPS 140-2) and provide recommendations to agencies on how they can comply with the requirements in various scenarios, i.e., remote access, email, data transfers, mobile devices and media, databases and applications. <\/p>\n
Under the law (Internal Revenue Code Section 6103(p)), IRS must protect all the personal and financial information furnished to the agency against unauthorized use, inspection, or disclosure. Other Federal, State, and local authorities who receive FTI directly from either the IRS or from secondary sources must also have adequate security controls in place to protect the data received. In order to ensure the confidentiality and integrity of FTI, data encryption is an essential element to any effective information security system. It can be used to safeguard against unauthorized disclosure, inspection, modification or substitution of FTI. IRS Publication 1075 utilizes the encryption requirements of NIST SP 800-53 and FIPS 140-2 to constitute the encryption requirements agencies in receipt of FTI must comply with. <\/p>\n
IRS Publication 1075 has adopted a sub-set of the moderate-impact security controls as its security control baseline for its compliance purpose. Among those, the below table depicts a list of encryption-related security controls that need to be implemented in order to comply with Publication 1075. <\/p>\n
NIST 800-53 - Recommended Security Controls for Federal Information Systems. <\/p>\n
FIPS 140-2 Security Requirements for Cryptographic Modules <\/p>\n
NIST 800-52 guidance on the use of Transport Layer Security (TLS) <\/p>\n
NIST 800-77 guidance on the use of IPsec <\/p>\n
NIST 800-52 guidance on the use of Transport Layer Security (TLS) <\/p>\n
NIST 800-77 guidance on the use of IPsec <\/p>\n
NIST 800-56 guidance on cryptographic key establishment <\/p>\n
NIST 800-57 guidance on cryptographic key management <\/p>\n
FIPS 140-2 is the mandatory standard for cryptographic-based security systems in computer and telecommunication systems (including voice systems) for the protection of sensitive data as established by the Department of Commerce in 2001. When the system implements encryption to protect the confidentiality and\/or integrity of the data at rest or in transit then the software or hardware that performs the encryption algorithm must meet FIPS 140-2 standards for encryption keys, message authentication and hashing. <\/p>\n
For a list of approved security functions and commonly used FIPS-approved algorithms, see the FIPS 140-1 and FIPS 140-2 Cryptographic Module Validation Lists which contains a list of vendors who have cryptographic modules validated as conforming to FIPS 140-2 are accepted by the Federal government for the protection of sensitive information. <\/p>\n
When considering the implementation of encryption technology, agencies should verify the cryptographic module of the product being implemented is FIPS 140-2 validated and on the vendor list. <\/p>\n
NIST 800-53 defines remote access as any access to an organization information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. <\/p>\n
IRS Publication 1075 states that accessing systems containing FTI from a remote location requires an encrypted modem and\/or Virtual Private Network (VPN). The key feature of a VPN is its ability to use public networks like the Internet without sacrificing basic security. Encryption and tunneling protocols are used to ensure the confidentiality of data in transit. Agencies should use IPSec or SSL encrypted VPN solutions and Point-to-Point Tunneling Protocol (PPTP), IPSec or L2TP tunneling protocols to establish VPN connections. <\/p>\n
Additionally, two-factor authentication i.e., something you know (e.g., password, PIN), and something you have (e.g., cryptographic identification device, token), is recommended whenever FTI is being accessed from an alternate work location. <\/p>\n
Within the agencys local area network, a secure network access protocol such as Secure Shell (SSH) should be used in place of traditionally insecure protocols such as telnet, rsh and rlogin for login to a shell on a remote host or for executing commands on a remote host. <\/p>\n
IRS Publication 1075 states e-mail systems shall not be used to transmit FTI data. Under the circumstances where there is an agency business requirement to use e-mail to transmit FTI, both the FTI data and message itself must be encrypted to protect the confidentiality of FTI. <\/p>\n
Most commonly used ways to protect electronic messages are: <\/p>\n
When messages require encryption, it is usually digitally signed also to protect its confidentiality. Therefore, the most frequently used way is the combination of the first 2 methods. The third method is used when two organizations want to protect the entire messages, including email header information sent between them. According to NIST SP 800-45, the most widely used standards for signing messages and encrypting message bodies are Open Pretty Good Privacy (OpenPGP) and Secure\/Multipurpose Internet Mail Extensions (S\/MIME) which both use public key cryptography. The most frequently used public key cryptography is Symmetric key cryptography. See NIST SP 800-45, Guidelines on Electronic Mail Security for general recommendations for selecting cryptographic suites for protecting email messages. <\/p>\n
Additionally, all documents sent to the IRS Safeguards email box containing Safeguard Review Reports (SRR), Safeguard Activity Reports (SAR), Safeguard Procedure Reports (SPR), or any other documentation deemed sensitive to the agency shall be compressed into a ZIP file and encrypted using WinZip with the 256-bit AES encryption option or transmitted using Secure Data Transfer (SDT). <\/p>\n
Internal (within agency LAN) <\/p>\n
Encryption of FTI data transfers within an agencys LAN is not currently required by Publication 1075. However, when considering defense-in-depth, encryption FTI transmitted within the Local Area Network (LAN) is a good security practice. For example, Secure FTP or FTP tunneled over SSH should be used instead of FTP for file transfers. <\/p>\n
For instances where encryption is not used for internal FTI transmissions, the agency must use other compensating mechanisms (e.g., switched Virtual LAN (VLAN) technology, fiber optic medium, etc.) to ensure that traffic containing FTI is isolated from the rest of the agencys LAN traffic, and the FTI is not accessible to unauthorized users. <\/p>\n
External (outside agency LAN) <\/p>\n
All FTI that is transmitted over the Internet, including via e-mail to external entities must be encrypted. This includes all FTI data transmitted across an agencys Wide Area Network (WAN). <\/p>\n
All application user sessions, whether those be client\/server or web-based applications, that access FTI from a back-end database or other server shall be encrypted and provide end-to-end encryption, i.e., from workstation to point of data. <\/p>\n
It is recommended that all data transmissions between the server and the workstation occur over a VPN that employs FIPS 140-2 compliant end-to-end encryption. If a VPN solution is not feasible, then an alternate end-to-end encryption mechanism such as using HTTPS protocol and Secure Sockets Layer (SSL)v3 (TLS) encryption is acceptable. SSL encryption should be based on a certificate containing a key no less than 128 bits and FIPS 140-2 compliant. <\/p>\n
While encryption of data at rest is an effective defense-in-depth technique, encryption is not currently required for FTI while it resides on a system (e.g., in files or in a database) that is dedicated to receiving, processing, storing or transmitting FTI, is configured in accordance with the IRS Safeguards Computer Security Evaluation Matrix (SCSEM) recommendations and is physically secure restricted area behind two locked barriers. This type of encryption is being evaluated by the IRS as a potential policy update in the next revision of the Publication 1075. <\/p>\n
However, if a system is used to receive, process, store or transmit FTI that also serves a secondary function not related to FTI processing (e.g., a workstation used to download FTI files from Secure Data Transfer system also serves as an employees user workstation), and this system does not meet the IRS SCSEM recommendations for secure configuration and physical security, the FTI residing on that system should be encrypted using FIPS 140-2 compliant encryption. This can be accomplished for example, using the Encrypting File System (EFS) on Windows 2000, XP and 2003 Server systems with the AES encryption algorithm. <\/p>\n
All FTI maintained on mobile media shall be encrypted with FIPS 140-2 validated data encryption and, where technically feasible, user authentication mechanisms. This encryption requirement applies all portable electronic devices, regardless of whether the information is stored on laptops, personal digital assistants, diskettes, CDs, DVDs, flash memory devices, or other mobile media or devices. <\/p>\n
Full disk encryption is an effective technique for laptop computers containing FTI that are taken out of the agencys physical perimeter and therefore outside of the physical security controls afforded by the office. Full disk encryption encrypts every bit of data that goes on a disk or disk volume and can be hardware or software based. Microsoft Windows Vista includes a form of full disk encryption called BitLocker Drive Encryption which uses the AES encryption algorithm with a 128 bit key. <\/p>\n
The IRS does not recommend full disk encryption over file encryption or vice versa, agencies can make a decision on the type of technology they will employ as long as it is FIPS 140-2 validated encryption. <\/p>\n
Page Last Reviewed or Updated: 13-Jan-2015 <\/p>\n
<\/p>\n