FAST FILE TRANSFER INFORMATION ASSURANCE ASSESSMENT REPORT

Transcription

1 DEFENSE INFORMATION SYSTEMS AGENCY JOINT INTEROPERABILITY TEST COMMAND INDIAN HEAD, MARYLAND FAST FILE TRANSFER INFORMATION ASSURANCE ASSESSMENT REPORT DOC NR: 5G OCTOBER 2007

2 FAST FILE TRANSFER INFORMATION ASSURANCE ASSESSMENT REPORT OCTOBER 2007 Submitted by: Adam K. Britt Chief, Information Assurance Branch Approved by: Gary M. Metcalf Chief, Homeland Security and Information Assurance Portfolio Prepared Under the Direction of: Ronald Ford JITC Action Officer Joint Interoperability Test Command Indian Head, Maryland

3 (This page intentionally left blank.)

4 EXECUTIVE SUMMARY The Joint Interoperability Test Command (JITC) is an independent evaluator of information systems deployed within the Department of Defense (DoD) and is one of the responsible organizations that conducts Interoperability (IOP) and Information Assurance (IA) testing of network components that will be connected to or operate over the Global Information Grid (GIG). The Office of the Assistant Secretary of Defense for Public Affairs (OASDPA) requested that the JITC perform an IA assessment of the Fast File Transfer (FFT) client and server software applications, which were developed by Northrop Grumman Mission Systems. This assessment took place at the JITC Indian Head, Maryland, test facility from August 15 through August 20, During this assessment, a series of tests were performed on the FFT v2.4 client and server software applications in an environment similar to that deployed throughout the DoD GIG. The goal of this assessment was to identify and assess any deficiencies that required correction in order for the FFT applications comply with DoD requirements to operate over the Unclassified-but- Sensitive Internet Protocol Router Network (NIPRNet) and Secret Internet Protocol Router Network (SIPRNet). The assessment revealed the FFT v2.4 client and server software applications worked in a simulated GIG network environment without any major findings, data packets were sent from the server to the client machine with out any packets being lost or altered while in transit. Data integrity was maintained through extensive error detection during the testing phase and no physical evidence of easily decrypted or decoded format was found. Based on the test results the FFT client and server applications should be ready to submit to the Defense Information Systems Network (DISN) Security Accreditation Working Group (DSAWG) for recommendation to operate over the NIPRNet and the SIPRNet.

5 (This page intentionally left blank.) ii

6 TABLE OF CONTENTS Page EXECUTIVE SUMMARY... i SYSTEM FUNCTIONAL DESCRIPTION... 1 TEST BACKGROUND... 1 TEST PURPOSE... 1 SCOPE... 2 TEST ENVIRONMENT... 3 LIMITATIONS... 4 METHODOLOGY... 4 TEST RESULTS... 4 ANALYSIS... 6 CONCLUSION... 7 LIST OF APPENDICES ACRONYMS... A-1 REFERENCES... B-1 POINTS OF CONTACT...C-1 LIST OF FIGURES 1 Simulated End-To-End Test Network Environment... 3 iii

7 (This page intentionally left blank.) iv

8 SYSTEM FUNCTIONAL DESCRIPTION Northrop Grumman Mission Systems Fast File Transfer (FFT) version 2.4 (v2.4) product consists of Microsoft-Windows-based client and server software applications that provide a mechanism for transferring data files in an encrypted format at a fast transfer rate while maintaining internal file integrity. The FFT v2.4 client and server software applications are designed to overcome many of the existing problems with current technologies for transferring large files, such as unencrypted data transfer, incomplete transfers, and inefficient use of available network bandwidth. The FFT v2.4 solution to these problems has been accomplished by breaking up each file transmitted into small data segments, encrypting the contents, and then sending the segments over multiple data streams simultaneously. A side-effect of this data segmentation is increased network reliability over low-speed, high-latency, communication links, such as satellite connections. TEST BACKGROUND This assessment supports the Office of the Assistant Secretary of Defense for Public Affairs (OASDPA) ultimate goal of obtaining Defense Information Systems Network (DISN) Security Accreditation Working Group (DSAWG) accreditation/certification to operate FFT v2.4 over the Unclassified-but-Sensitive Internet Protocol Router Network (NIPRNet) and the Secret Internet Protocol Router Network (SIPRNet) as an alternative to File Transfer Protocol (FTP). The FFT v2.4 was originally developed as a commercial application; formal government testing has been previously performed on a previous FFT v2.4 to identify its Information Assurance (IA) posture or how the client and server applications would operate within the Joint environment. According to Department of Defense (DoD) Directive (DoDD) (paragraph 4.2), all DoD information systems shall maintain an appropriate level of confidentiality, integrity, authentication, non-repudiation, and availability that reflects a balance among the importance and sensitivity of the information and assets; documented threats and vulnerabilities; the trustworthiness of users and interconnecting systems; the impact of impairment or destruction to the DoD information system; and cost-effectiveness. TEST PURPOSE The goal of this assessment was to evaluate the IA posture of the FFT v2.4 client and server software applications, while operating within a simulated DoD Global Information Grid (GIG) network environment. Additionally, the assessment identifies any deficiencies/vulnerabilities that would require correction in order for the FFT v2.4 to move forward in obtaining accreditation/certification to operate over the NIPRNet and the SIPRNet. 1

9 SCOPE The scope of this assessment consisted of the following activities: Capture and analyze data transmissions between the FFT v2.4 client and server applications in the proposed test environment configurations to identify: - Any authentication credentials transmitted in clear text or other easily decrypted/decoded formats - Any data transmitted in clear text or other easily decrypted/decoded format - The Transmission Control Protocol/Internet Protocol (TCP/IP) network ports used - The type and size of TCP/IP packets used - The smallest, largest, mean, and median sizes of the TCP/IP packets transmitted during the test - Any potential fingerprints that the FFT v2.4 and/or its protocol left in the data transmissions Identify and validate the FFT v2.4 client and server applications methods/capabilities for: - Controlling access to the following functions: Administration Configuration Program execution File system navigation File uploading (write) File downloading (read) File over-writing (append) - The FFT v2.4 software applications adherence to file access rights and permissions that exist at the file-system level - The FFT v2.4 software server components capabilities to restrict access to a fixed root directory on a host file system - The FFT v2.4 software components capabilities to record and maintain auditing information in accordance with the DoD and CJCS requirements - The FFT v2.4 software components compliance with DoD and CJCS user authentication requirements - The FFT v2.4 software components compatibility with Internet Protocol version 6 (IPv6) 2

10 - All cryptographic modules used by the FFT v2.4 software application and their compliance with Federal Information Processing Standard (FIPS) 140-2, Security Requirements for Cryptographic Modules Validate the FFT v2.4 application s authentication system, as follows: - Perform a series of authentication attempts using various username / password combinations that are authorized to connect to the FFT v2.4 server application - Perform a series of authentication attempts using various username/ password combinations that are not authorized (incorrect or invalid) to connect to the FFT v2.4 server application Validate the integrity of files after transmission by transmitting a series of various sized files from the server to the client using the FFT v2.4 software components Validate the preservation of filenames by transmitting a series of files, using various filename lengths and characters within the Latin-1 character set, from the server to the client using the FFT v2.4 software components TEST ENVIRONMENT To accomplish the FFT v2.4 assessment, the JITC designed and used a network architecture that simulates the DoD environment. Figure 1 illustrates the simulated endto-end network environment, as it appeared during test execution. Figure 1. Simulated End-to-End Test Network Environment To ensure that testing encompassed the majority of the Microsoft-Windowsbased Operating Systems (OS) currently deployed within the DoD GIG, the following Microsoft Windows test-environment configurations were used: 3

11 Microsoft Windows 2000 Professional non-domain-based configuration Microsoft Windows 2000 Professional domain-based configuration Microsoft Windows 2000 Server non-domain-based configuration Microsoft Windows 2000 Server domain-based configuration Microsoft Windows 2000 Server domain-controller-based configuration Microsoft Windows XP Professional non-domain-based configuration Microsoft Windows XP Professional domain-based configuration Microsoft Windows 2003 Server non-domain-based configuration Microsoft Windows 2003 Server domain-based configuration Microsoft Windows 2003 Server domain-controller-based configuration All operating system configurations were secured using the most current Security Technical Implementation Guides (STIG) available from the DISA Field Security Operations (FSO) and the National Security Agency (NSA). LIMITATIONS The JITC verifies the compliance of the FFT v2.4 software application s cryptographic modules with FIPS by reviewing the FFT v2.4 technical documentation. Only the National Voluntary Laboratory Accreditation Program (NVLAP) accredited Cryptographic Modules Testing (CMT) laboratories are authorized to test cryptographic modules; the JITC is not an NVLAP-accredited laboratory. METHODOLOGY To properly assess the IA posture of the FFT v2.4 client and server software applications, the JITC reviewed all applicable DoD and CJCS directives, manuals, memorandums, and instructions relevant to the FFT v2.4 and its potential future operating environments. Thereafter, the JITC developed a series of tests encompassing the broadest possible range of identified IA requirements. TEST RESULTS During the test phase of this assessment, a large amount of data was gathered from several points in the network test environment using a packet analysis tool. As part of the data-reduction process, the JITC analyzed the network data captured from data transmissions. From this analysis, the JITC identified some notable information, as detailed below. At no time during a data transmission between the FFT v2.4 client and server did the test team see any clearly identifiable data movement in a clear text format. All information contained within the application layer appeared in a scrambled format. As the JITC is not equipped to determine whether the data was being scrambled using a 4

12 specific encryption implementation, the test team could only confirm that no clear text was observed. Both the FFT v2.4 client and server software applications allow for a specific TCP/IP network port number to be used as part of its basic configuration. The default port number identified in the FFT v2.4 documentation, as well as in the FFT v2.4 configuration Graphical User Interface, was 923. This port number is currently listed as unassigned by the Internet Assigned Numbers Authority. The test team encountered no difficulty in using this port number during any of the tests. Aside from the configured TCP/IP network port number, the test team was unable to identify any fingerprints ; (i.e., clearly repeating patterns in the transmitted data). Access control of the FFT v2.4 client and server software applications was performed using the underlying OS access-control capabilities. The FFT v2.4 server application uses local Windows accounts and groups to define those users who are authorized to connect and transfer files. From results gathered during the tests, only an authorized active account had the permissions to launch the client application and was able to view and change the system-wide client configuration. The test team was unable to identify any means of restricting either the uploading or downloading capabilities when using an authorized FFT v2.4 account. All authorized accounts were able to upload and download any FFT v2.4 client - and/or serverreadable file. The FFT v2.4 server was found to have a built-in IA control measure to restrict access by remote users to the local file system. This measure places a remote user account into a configured root directory (commonly known as a chroot jail ). The remote user account, having been place into this directory, cannot traverse to a lower directory. Having this control enhances the IA posture of the FFT v2.4 server and serves as a part of a multi-layered protection system. At no time did the test team observe the FFT v2.4 client or server as overwriting an existing file. If a file already existed during a file transfer, the transferred filename was altered to append the date and time of the transfer in universal-time-coordinate format. Both the FFT v2.4 client and server respected the file access rights and permissions existing at the file-system level. If a file were configured to prevent a currently logged-on local Windows user from accessing it, the FFT v2.4 client would not transfer the file to the server. Conversely, the FFT v2.4 server would not transfer a file to the client if that file were configured to prevent the FFT v2.4 server from gaining access to it. According to a DoD 5000 series Memorandum from the Assistant Secretary of Defense (ASD) Chief Information Officer (CIO), assets being developed, procured, or acquired shall be IPv6-capable (in addition to maintaining interoperability with IPv4 systems/capabilities). As this requirement will play a part in the accreditation/certification of the FFT v2.4 client and server software applications to 5

13 operate over the NIPRNet and SIPRNet, tests were run to confirm the FFT v2.4 s IPv6 capability. The test hosts were configured to use IPv6 networking, and a connection was made between the FFT v2.4 client and server by using the IPv4 address of the host running the FFT v2.4 server application. This connection was made successfully, indicating that FFT v2.4 will operate on Windows hosts having both IPv4 and IPv6 enabled. The test team s review of the provided FFT v2.4 documentation neither confirmed nor denied the vendors stance on IPv6 support within the FFT v2.4 applications. No future support roadmap was identified, nor were there any indications that an IPv6 implementation was present in the applications. Testing was performed to ensure the FFT v2.4 client and server software applications accepted account credentials (i.e., usernames and passwords) that met the DoD and CJCS requirements, as defined in CJCS Manual (CJCSM) , CJCS Instruction (CJCSI) D, DoD Directive (DoDD) , and DoD Instruction (DoDI) All tested password combinations were successfully accepted. Enforcement of a password policy to ensure that these requirements were met was outside the scope of the FFT v2.4 application, as they use the underlying Windows authentication system that controls the applications password policy. Several tests were performed using various user accounts to determine whether the authentication system would prevent connecting unauthorized accounts. Each test confirmed that the authentication system would prevent access if the account were disabled, not a member of the defined FFT v2.4 account group, or invalid. The test team identified documentation indicating the FFT v2.4 client and/or server applications made use of a FIPS certified cryptographic module. Additional information regarding encryption was a reference to the use of Data Encryption Standard (DES); a standard based upon an encryption algorithm acknowledged by both the National Security Agency (NSA) and the National Institute of Standards and Technology (NIST), as well as defined by FIPS Publication (PUB) To ensure the integrity of transferred files, the test team executed a series of tests to compare the cryptographic signature hashes of all transferred files. For each file that was successfully transferred, the signature was identical, before and after transfer, thereby confirming that the integrity of the file was maintained. ANALYSIS During an extensive review of the previously DSAWG-defined protocols, along with guidance on implementation (or removal) of protocols, the test team identified three specific protocols that are similar to that of FFT v2.4: FTP, FTP over Secure Socket Layer (FTPS), and Secure Shell. 6

14 Conversations with the vendor verified that the encryption functions used by the FFT v2.4 rely upon the underlying cryptography Application Program Interface (API) of the Windows OS. Since this is the case, the test team believes that the vendor has met this requirement. This should give the FFT v2.4 a better chance of obtaining a higher assurance level when the DSAWG reviews it for inclusion in the Ports, Protocols, and Services Assurance Category Assignment List. Based upon observations during the permission-assignment tests, the FFT v2.4 server application appears to execute under a local, non-system account but does not provide any functionality besides listening to incoming connections. The underlying Windows authentication system has built-in auditing capabilities that are enabled whenever a host is configured following a DISA STIG. When authentication requests come in from the FFT v2.4 server application, then these events are all logged into the main security event log. CONCLUSION The testing and analysis of the FFT v2.4 client and server software applications revealed the FFT v2.4 made the recommended changes to its client and server software and has conformed to the requirements placed by the DoD. The FFT v2.4 client and server software applications should be able to proceed with the accreditation/certification process as determined by the vendor/sponsor. 7

15 APPENDIX A ACRONYMS AIS API ASD CIO CJCS CJCSM CJCSI CMT DES DISA DISN DoD DoDD DoDI DSAWG FFT FIPS FSO FTP FTPS GIG Automated Information Systems Application Programming Interface Assistant Secretary of Defense Chief Information Officer Chairman, Joint Chiefs of Staff Chairman, Joint Chiefs of Staff Manual Chairman, Joint Chiefs of Staff Instruction Cryptographic Modules Testing Data Encryption Standard Defense Information Systems Agency Defense Information Systems Network Department of Defense Department of Defense Directive Department of Defense Instruction Defense Information Systems Network (DISN) Security Accreditation Working Group Fast File Transfer Federal Information Processing Standard Field Security Operations File Transfer Protocol File Transfer Protocol over Secure Socket Layer Global Information Grid IA Information Assurance IOP Interoperability IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 JITC NII NIPRNet NIST NSA NVLAP Joint Interoperability Test Command Network and Information Integration (ASD) Unclassified-but-Sensitive Internet Protocol Router Network National Institute of Standards and Technology National Security Agency National Voluntary Laboratory Accreditation Program A-1

16 ACRONYMS (continued) OASDPA OS PKI PUB SIPRNet STIG TCP/IP Office of the Assistant Secretary of Defense for Public Affairs Operating System Public Key Infrastructure Publication Secret Internet Protocol Router Network Security Technical Implementation Guide Transmission Control Protocol/Internet Protocol A-2

17 APPENDIX B REFERENCES Chairman, Joint Chiefs of Staff (CJCS) Manual (CJCSM) , Defense in Depth: Information Assurance (IA) and Computer Network Defense (CND), Change 3, 8 March 2006 CJCS Instruction (CJCSI) D, Information Assurance (IA) and Computer Network Defense (CND), 15 June 2004 Department of Defense Directive (DoDD) , Information Assurance, 24 October 2002 DoDI , Information Assurance Implementation, 06 February 2003 Department of Defense Instruction (DoDI) Memorandum, Internet Protocol Version 6 (IPv6), Assistant Secretary of Defense/Networks and Information Integration (ASD/NII) Chief Information Officer (CIO), 9 June 2003 Federal Information Processing Standard (FIPS) Publication (PUB) 46-3, Data Encryption Standard (DES), 25 October 1999 FIPS 140-2, Security Requirements for Cryptographic Modules, 25 May 2001 Ports, Protocols, and Services (PPS) Assurance Category Assignments List, Release 5.6, Defense Information Systems Agency (DISA), March 2006 B-1

18 (This page intentionally left blank.) B-2

19 APPENDIX C POINTS OF CONTACT NAME ORGANIZATION PHONE/E MAIL Britt, Adam JITC IA Chief (GOVT) Ford, Ronald JITC IA AO Gourdin, Vaughn NGMS Task Lead (CONT) Mercado, Freddy NGMS Program Manager (CONT) Joint Interoperability Test Command 3341 Strauss Avenue, Suite 236 Indian Head, MD Joint Interoperability Test Command 3341 Strauss Avenue, Suite 236 Indian Head, MD Joint Interoperability Test Command 3341 Strauss Avenue, Suite 236 Indian Head, MD Joint Interoperability Test Command ATTN: NGMS 3341 Strauss Avenue, Suite 236 Indian Head, MD (301) DSN Fax (301) E mail: Adam.Britt@disa.mil (301) DSN Fax (301) E mail: Ronald.Ford@disa.mil (301) DSN Fax (301) E mail: Vaughn.Gourdin.ctr@disa.mil (301) DSN Fax (301) E mail: Freddy.Mercado.ctr@disa.mil C-1

20 (This page intentionally left blank.) C-2