Joint Interoperability Test Command Fort Huachuca, Arizona
DEFENSE INFORMATION SYSTEMS AGENCYJOINT INTEROPERABILITY TEST COMMANDFORT HUACHUCA, ARIZONAREAL TIME SERVICESINFORMATION ASSURANCETEST PLANFEBRUARY 2009
REAL TIME SERVICESINFORMATION ASSURANCETEST PLANFEBRUARY 2009Submitted by:Approved by:Joseph SchulteChief, Network Systems Branchfor RICHARD A. MEADORChief, Battlespace Communications PortfolioPrepared Under the Direction of:Michael NapierJoint Interoperability Test CommandFort Huachuca, Arizona
(This page intentionally left blank.)
EXECUTIVE SUMMARYThe Department of Defense (DoD) Directive 8500.1 “Information Assurance (IA),”24 October 2002, established the DoD policies for IA and directed that all informationtechnology systems be IA tested and certified before connection to the DefenseInformation System Network (DISN). The DoD Instruction 8100.3, “Department ofDefense Voice Networks,” 16 January 2004, established the IA policy for DoD VoiceNetworks, including the Defense Switched Network (DSN). The Real Time Services(RTS) IA Unified Capabilities Requirements (UCR) document established therequirements for securing RTS systems. The DSN Single Systems Manager (SSM) isresponsible for providing DSN IA test results to the DISN Designated ApprovingAuthorities to grant IA certification and accreditation. The DSN SSM has designated theJoint Interoperability Test Command (JITC) as a responsible organization for DSN IAtesting.The JITC DSN IA Test Team (IATT) supports IA testing and the RTS IA UCR bydetermining the compliance of products before their use on DISN. Compliance methodsinclude the Security Technical Implementation Guidelines, IA Vulnerability Managementannouncements (e.g., alerts, bulletins, and technical guidance), and IA requirements. Inaddition, the IATT performs scans for Internet Protocol (IP) vulnerabilities to determinethe residual risks and threat levels of existing security implementations and/or thediscovered security deficiencies. When systems meet the RTS IA requirements, this willallow the DSN to migrate smoothly from the current military-unique features of a circuitswitched service to a converged net-centric IP-based assured secure RTS in a mannerconsistent with the Defense Information Systems Agency (DISA) IP Convergence MasterPlan.Upon completion of IA testing, the IATT will analyze the data collected andpresent the test findings in an “IA Assessment Findings and Mitigations Report.” Thisreport will contain the IATT’s findings for the system assessed and will identify the IAcompliance status strategies. The IATT will deliver this report to the vendor so that thevendor may add any mitigation solutions. The assessment report, including thevendor’s mitigation strategy, will be submitted to the Unified Capabilities ConnectionOffice and the DISA Field Security Office (FSO) for comment. The FSO will write acertification and accreditation letter to the DISN Security Accreditation Working Group(DSAWG) and will brief the final assessment report to the DSAWG in a PowerPointpresentation. The DSAWG will decide whether to place the vendor’s system on theUnified Capabilities Approved Products List, based on the findings and mitigations.
(This page intentionally left blank.)ii
TABLE OF CONTENTSPageEXECUTIVE SUMMARY.iINFORMATION ASSURANCE DESCRIPTION .1INFORMATION ASSURANCE BACKGROUND .2DEFENSE-IN-DEPTH AND REQUIRED ANCILLARY EQUIPMENT (RAE) .3INFORMATION ASSURANCE PURPOSE .3REQUIREMENTS .3SCOPE.4Roles of UCR 2008 and Generic System Specification (GSS) Documents .5LIMITATIONS.6METHODOLOGY .7Certification Process Overview. .7TESTING METHODOLOGY .10Test Packet.10Vendor Documentation. .11Functionality Tests. .12RTS-SPECIFIC REQUIREMENTS AND METHODOLOGY.12STIG ASSESSMENT METHODOLOGY. .13RTS IA REQUIREMENTS METHODOLOGY.15IP VULNERABILITY (IPV) TESTING/PROTOCOL ANALYSIS METHODOLOGY.16MANAGEMENT STIG/RTS STIG.19MANAGEMENT TRAFFIC .21MANAGEMENT CONNECTIONS METHODS .22APPENDICESACRONYMS . A-1RESOURCES AND TOOLS. B-1TEST PREPARATION DOCUMENTS .C-1DSN ARCHITECTURE.D-1ASSESSMENT OBJECTIVES, CRITERIA, PROCEDURES,AND DATA REQUIRED. E-1REFERENCES. F-1POINTS OF CONTACT.G-1LIST OF FIGURES123Overview of the Relationship Among the RTS UCR, ISPs, KIPs, and RTSArchitecture .6IA and IO APL Certification Process Flow .8Sample Diagram for Submission .11iii
TABLE OF CONTENTS (continued)LIST OF FIGURES 8E-9E-10E-11E-12E-13E-14E-15IASE Website . B-6NSA Website . B-7Toggle Buttons . B-12DSN Architecture.D-1Information Assurance STIG Testing Process. E-1Security Configuration and Analysis . E-14Configure Your Computer. E-15Analyzing System Security . E-15Analysis Objects . E-16IE Warning Message . E-17IE Message Box . E-17IE Dialog Box. E-18Explorer Window . E-19IE Warning Message . E-19Message Box. E-19Dialog Box . E-20Reporting Selection Buttons . E-20DIACAP Lifecycle . E-21DoD Information Systems. E-22LIST OF TABLES12345B-1B-2B-3B-4B-5E-1E-2E-3E-4E-5E-6ETSI TIPHON Threat Likelihood Scoring Criteria .13ETSI TIPHON Threat Impact Scoring Criteria .13SUT IA Test Summary.19Additional IA Requirements (GR-815 CORE) .20RTS STIG Sections .21STIG Listing. B-2IA Control Subject Areas . B-9IA Control Details. B-13DISN RTS UCR Documentation Components . B-16IPV Test Tools . B-18Gold Disk Minimum System Requirements . E-4DISA Gold Disk Test Procedure . E-5DISA Gold Disk Test Procedure Alternate No Optical Drive . E-6DISA Gold Disk Test Procedure Alternate Command Line. E-7SRR Test Procedure. E-8Types of Appliance Components Used . E-27iv
TABLE OF CONTENTS (continued)LIST OF TABLES 41E-42E-43E-44General Requirements . E-28Authentication . E-35Integrity . E-139Confidentiality . E-148Non Repudiation . E-171Availability . E-181IPv6 Requirements . E-184RTS Internet Protocol Vulnerability Testing . E-234SS7 Protocol Security Analysis . E-247ISDN Protocol Security Analysis . E-258CAS Protocol Security Analysis . E-260Ping Sweep Test Procedures . E-265TCP Sweep Test Procedures . E-266Traffic Analysis Test Procedures . E-267Port Enumeration Test Procedures . E-268Service Enumeration Test Procedures . E-269Service Analysis Test Procedures . E-269Vulnerability Assessment Test Procedures . E-270Application Assessment Test Procedures . E-271DoS Test Procedures . E-272Exploitation and Injection Test Procedures . E-273Password Cracking Test Procedures . E-274SIP Enumeration . E-275SIP Vulnerability Assessment. E-275SIP Fuzzing . E-276Eavesdrop on a SIP Subscriber’s Transport Data . E-277Corrupt a SIP Subscriber’s Transport Data . E-277Masquerade as a Valid SIP Subscriber . E-277Eavesdrop on a SIP Subscriber’s Signaling Data. E-277Corrupt a SIP Subscriber’s Signaling Data. E-278Eavesdrop on RTS Network Management Data. E-278Corrupt RTS Network Management Data. E-278Attempt to Obtain an RTS End Instrument Telephone Number. E-279SIP Denial of Service. E-279Man-In-The-Middle Attack . E-279Attempt a Replay Attack (RTP and Signaling) . E-280Illegal Registration . E-280Illegal De-Registration . E-281v
(The page intentionally left blank.)vi
INFORMATION ASSURANCE DESCRIPTIONThe Department of Defense (DoD) Directive 8500.1 “Information Assurance (IA),”24 October 2002, established DoD policies for IA and directed that all informationtechnologies be IA tested and certified before connection to the Defense InformationSystem Network (DISN). The DoD Instruction (DoDI) 8100.3, “Department of DefenseVoice Networks,” 16 January 2004, established the IA policy for DoD Voice Networks,including the Defense Switched Network (DSN). The DSN Single Systems Manager(SSM) is responsible for providing DSN IA test results to the DISN DesignatedApproving Authorities to grant the IA certification and accreditation. The DSN SSM hasdesignated the Joint Interoperability Test Command (JITC) as a responsibleorganization for DSN IA testing.The purpose of this document and its appendices is to provide information andguidance on Real Time Services (RTS) that must be used to acquisition all hardwareand software that support RTS. The RTS Unified Capabilities Requirements (UCR)2008 document is used to do the following: Establish standards and specifications needed by industry to developcompliant RTS solutions.Provide the foundation for the development and finalization of GenericSystem Test Plans for interoperability testing and IA Test Plans for IA testing.These tests assist in making decisions necessary to place products on theDoDI 8100.3 Approved Product List (APL) so that combatant commands,services, and agencies can purchase them.Provide the foundation for the development and finalization of the SecurityTechnical Implementation Guidelines (STIG).Establish those STIGs needed to operate the approved products onceinstalled in a secure manner.The IA testing phases cover several areas. The first is the STIG testing phase,which assesses the system’s ability to operate reliably in a secure environment. TheSTIG testing also evaluates the system’s management interface. The Internet Protocol(IP) Vulnerability (IPV) phase covers the system’s ability to resist attack and determineswhether the system operates securely in an IP network. Appendix B lists therequirements used for assessments, and Appendix E lists the specific procedures foreach phase of testing.The architecture of the DSN is a two-level network hierarchy consisting ofbackbone switches and infrastructure (managed by the Defense Information SystemsAgency (DISA)) and installation switches and peripherals (managed by militarydepartments and agencies).This two-level network hierarchy includes the following: The first level consists ofcomponents under test, which includes Tandem Switches, Multifunction Soft Switches(MFSS), Signal Transfer Points (STP), Network Management Systems, End Office (EO)1
Switches, Private Branch Exchange (PBX) Types 1 and 2, Small End Office Switches,and Local Session Controllers (LSC). The second level is the backbone of theinfrastructure, which consists of Deployable Voice Exchanges, Remote Switching Units,Video Teleconferencing, Customer Premise Equipment, Edge Bounder Controllers(EBC), Network Elements, Echo Cancellers, Integrated Access Switches/Systems,Assured Services Local Area Networks, and Conference Bridge.The DSN provides end-to-end command and control (C2) capability viadedicated telephone service, facsimile, voice-band data, dial-up firewalls, IP Security(IPSec), and Transport Layer Security. The DSN comprises backbone and tandemswitches, signaling system instruments, transmission connectivity between switches,installation switches, network management systems, and end devices. Voiceprocessing and transport technologies, such as Voice over Internet Protocol (VoIP) andpacketized Voice over Asynchronous Transfer Mode, are also elements of the DSN.The RTS IA architecture and the associated UCR 2008 for the Sensitive-ButUnclassified architectures are described in the RTS UCR 2008. The DISN RTS UCR2008 will ensure that the high-quality mission-critical interoperability and IA preservetoday’s technologies as the migration to IP is successfully accomplished.INFORMATION ASSURANCE BACKGROUNDVendors are continuously developing new features and functions to meet userdemands and to correct any deficiencies within the solution. As of January 2004, DoDI8100.3 mandates all systems that connect to or will connect to the DSN undergo IAcertification. The APL is the only listing of equipment authorized by DoD to be fielded inthe DISN. The first part of the APL Certification Process is IA accreditation testing (e.g.,DSN IA testing). If the product does not meet the requirements for IA accreditation, itreturns to the vendor for correction and the testing cycle starts over. If the solutionmeets the requirements for IA accreditation, it continues to the second part of the testcycle, Interoperability (IO) testing. When IA accreditation and IO certification aregranted, the solution is then included on the Unified Capabilities (UC) APL. A productwill not progress to an RTS assessment unless its baseline has received certification.To enhance the vendor’s IA posture and readiness strategy, JITC conducts IAassessments of vendors’ products before they undergo IO certification. ProgramManagers or DoD agencies must obtain IA accreditation for all telecommunicationequipment that is procured for use on the DSN, whether the equipment is new or is anupdated version of equipment already in the DSN. Those DoD information systemsmust also identify, implement, and manage IA Controls based on the DoD IACertification and Accreditation (C&A) Process (DIACAP), as described in Appendix B,paragraph B-3.2
DEFENSE-IN-DEPTH AND REQUIRED ANCILLARY EQUIPMENT (RAE)The DoD approach for establishing an adequate IA posture in a shared-riskenvironment that allows for shared mitigations is through the following: the integrationof people, technology, and operations; the layering of IA solutions within and amongInformation Technology (IT) assets; and the selection of IA solutions based on theirrelative level of robustness. This combination produces layers of technical and nontechnical solutions that do the following: provide appropriate levels of confidentiality,integrity, authentication, non-repudiation, and availability; defend the perimeters ofenclaves; provide appropriate degrees of protection to all enclaves and computingenvironments; and make appropriate use of supporting IA infrastructures, to includerobust key management and incident detection and response.The use of RAE components can aid the site in developing and implementing itsPlan of Action and Milestones to supplement the DIACAP accreditation package. Useof this equipment or software provides additional security features to the existingenvironment, which may already be present in a government infrastructure and enforcedefense-in-depth. As a minimum, RAE may consist of one or a combination of thefollowing:1. Microsoft Windows Server 2003 Internet Authentication Service RemoteAuthentication Dial-In User Server (RADIUS) or Terminal Access ControllerAccess Control System Plus (TACACS )2. Active Directory3. SysLog Server4. Public Key InfrastructureINFORMATION ASSURANCE PURPOSEThe purpose of this RTS IA test plan is to provide a consistent set of guidelinesfor testers and developers to evaluate the operation of any switch system for theapplicable STIG, RTS IA requirements, and IPV requirements.REQUIREMENTSThe number of DoD regulations, policies, and guidance documents for securityrelated activities has grown significantly over the last several years as the DoDcommunity has devised standard IA practices to protect its assets and information.Government regulations now cover all aspects of IA, including the acquisition,deployment, and use of IA and IA-enabled IT products. Appendix F contains the full listof references. The JITC IA Test Team (IATT) will verify that each system tested willconform, at a minimum, to the requirements in the following documents: Chairman of the Joint Chiefs of Staff Instruction 6215.01B – This instructionestablishes policy and prescribes responsibilities for use and operation of the3
DoD voice networks, specifically the DSN and the Defense Red SwitchNetworkChairman of the Joint Chiefs of Staff Instruction 6510.01 – Provides detailsand further references for selecting and implementing security requirements,controls, protection mechanisms, and standardsDoD Instruction 8500.2 – Provides details and further references for selectingand implementing security requirements, controls, protection mechanisms,and standards. It also combines mission assurance categories andconfidentiality levels with best security practices, general threat information,federal and DoD policy requirements, and enterprise operational andtechnical considerations in a graded or banded risk modelFederal Information Processing Standards Publications (FIPS Pubs)140-2 – This standard specifies the security requirements that will besatisfied by a cryptographic module used within a security systemprotecting sensitive but unclassified informationDIACAP Guidance – Under this directive-type memorandum all DoDcomponents are to immediately follow the DoD C & A guidance for theoperation of all DoD information systems. This memorandumsupersedes existing DoD Information Technology Security C & AProcess (DITSCAP) guidance under DoDI 5200.40 and DoD 8510.1The National Information Assurance Partnership – This is a U.S.Government initiative originated to meet the security testing needs ofboth IT consumers and producers, and is operated by the NationalSecurity Agency.National Institute of Standards and Technology (NIST) Special Publication800-40 (Version 2) – Provides guidance on patch and vulnerabilitymanagementNIST Special Publication 800-42 – Provides guidance on network securitytestingNIST Special Publication 800-53 – Requires that vulnerability scanningbe conducted using appropriate scanning tools and techniques.These documents are available on the Internet, either free of charge or for alicensing fee.SCOPEThe RTS IA test plan covers both traditional telecommunications (Time DivisionMultiplexer/Multiplexing components) switching equipment and IP-enabled or IP-centricswitching equipment. The JITC IA process for evaluating VoIP products determines thesecurity level of individual VoIP- and IP-enabled products connected to the DSN or on aconverged network that is IP enabled from the trunk side as well as the line. The IAphase of testing consists of the following two phases: Phase I: STIG and Other IA Requirements. Phase I testing involvesapplying predetermined STIGs and other IA requirements to variouscomponents of the vendor solution and recording any discrepancies that may4
arise from application of the STIG. The STIG applicability is determined byattributes, such as the underlying operating system for the solution (e.g.,Windows, Linux, and UNIX), applications or services that operate on thesolution, and the overall functionality of the solution (e.g., MFSS, LocalSession Controller (LSC), Edge Border Controller (EBC), Private BranchExchange (PBX), router, switch, server, and workstation). Any individualsolution may require the application of one or multiple STIG. Otherrequirements from the IA UCR are also applied, and the RTS STIG applies tomanagement interfaces for the solutions. The lab assessment contains aDIACAP control correlation matrix (scorecard) that addresses the DoD IAControl. The DIACAP package, along with the IA report, can assist the site increating and implementing its baseline, providing a foundation for achievingits Interim Authority to Operate. Both requirements and implementationprocedures are discussed in Appendices B and E, respectively. Phase II: IP Vulnerability Scans/Protocol Analysis. Phase II consists ofscanning and/or attacking the vendor’s solution using the tools available to anattacker (or hacker) intent on penetrating a network or system. Vulnerabilityanalysis for custom software or applications protocols such as SignalingSystem 7 (SS7), Primary Rate Interface, Channel Associated Signaling,European Carrier 1 (E1), Telecommunications Carrier 1 (T1) SessionInitiation Protocol (SIP), and Secure Real-time Transport Protocol (SRTP)may require additional, more specialized approaches (e.g., vulnerabilityscanning tools for applications, source code reviews, and statistical analysisof source code). The scan results are packaged in human-readable form inportable document format (PDF) and are part of the DIACAP submission.Appendices B and E contain detailed procedures.Roles of UCR 2008 and Generic System Specification (GSS) Documents. TheUCR 2008 is used for acquisitions and with APL and IA testing that JITC conducts. TheGSSs were developed for the key technologies and capabilities critical tointeroperability, Assured Services SIP and the Wide Area Network (WAN). Eachrequirement from the UCR 2008 and GSS supports the collaborative development ofInformation Support Plans (ISP) and Key Interface Profiles (KIP) for programs that meetrequirements listed in Chairman of the Joint Chiefs of Staff Instruction (CJCSI)6212.01E need DISN RTS connection approval. Figure 1 provides an overview of therelationship among the RTS UCR 2008 and their associated test plans, ISPs and KIPs,and RTS architecture.5
ssured ServiceAssured Service Converged Local Area NetworkAssured Services Session Initiation ProtocolBase, Camps, Posts, and StationsConverged Area NetworkContinental United StatesDefense Information System NetworkEnd to EndGlobal Information GridGeneric System RequirementsGeneric Switch Test PlanInformation AssuranceInformation Assurance Test PlanInternet Protocol Version 6Information Support PlansKey Interface ProfilesLocal Area NetworkMetropolitan Area NetworkMilitary DepartmentOutside Continental United StatesReal Time ServicesSecure Data NetworkUnified Capabilities RequirementsWide Area NetworkFigure 1. Overview of the Relationship Among theRTS UCR, ISPs, KIPs, and RTS ArchitectureLIMITATIONSParts of the STIG are not assessed because the System Under Test (SUT) is notdeployed in an actual operational environment. The DIACAP Scorecard shows theseitems as “site responsibility” or “not applicable” for the SUT. Some of these itemsinclude aspects of enclave security, personnel qualifications, training, and contingencyplanning (e.g., disaster recovery plans, backups, storage of media, and incidentreporting). The RTS assessments include local network and firewall configuration andmeet appropriate standards. As part of the local C & A package the installers shouldassess these items, as well as other DoDI 8500.2 IA Controls, at the local site.6
METHODOLOGYThe RTS IATT performs assessments using the methodologies presented in thisplan. The methods cover Phase I and Phase II IA testing, including STIG testing andother IA requirements, IPV scanning tests, Protocol Analysis (PA) SS7, SIP, H.323, andSRTP protocol analysis testing.Certification Process Overview. Figure 2 depicts the steps in the IA and IO APLproduct certification process. The RTS accreditation process will follow the same stepsas the APL process. W
The RTS IA architecture and the associated UCR 2008 for the Sensitive-But- Unclassified architectures are described in the RTS UCR 2008. The DISN RTS UCR 2008 will ensure that the high-quality mission-critical interoperability and IA preserve today's technologies as the migration to IP is successfully accomplished. INFORMATION ASSURANCE .
Command Library - String Operation Command Command Library - XML Command Command Library - Terminal Emulator Command (Per Customer Interest) Command Library - PDF Integration Command Command Library - FTP Command (Per Customer Interest) Command Library - PGP Command Command Library - Object Cloning
Fort Bragg, NC Fort Leavenworth, KS Fort Campbell ,KY Fort Lewis WA Fort Carson, CO Fort McPherson, GA ,GA Fort Meade MD . Fort Belvoir CPAC Building 320 Training Dates Room Number Time 17 -19 March Room 140 0800 -1600 daily 24 -26 March Room 134 0800 -1600 daily
Fort Bragg NC, Fort Carson CO, Fort Gordon GA, Fort Hood TX, Fort Hunter Liggett CA, Fort Jackson SC, and Fort Sill OK. . (RSO) (U), 132138Z Apr 11 . Physical Security Plan for US Army Installation Management Command Ranges Affected by Depleted Uranium in
Other Shortcut Keys 28 Command Line Reference 30 Information for DaRT Notes Users 32 . Open command 39 Save command 39 Save As command 39 Close command 39 Recent Files command 39 Clear MRU List command 40 Remove Obsolete command 40 Auto Save command 40 Properties comman
Type the desired command or the command‟s alias at the command prompt. Command : LINE Command: L 2. Press ENTER on the keyboard. 3. Type an option at the command prompt. TIP: Many AutoCAD commands require you to press ENTER to complete the command. You know you are no longer in an AutoCAD command when you see a blank command line.
IBM eServer Bladecenter Interoperability Matrix 4-8 NPV Interoperability Matrix 4-10 iSCSI Interoperability 5-1 EMC 5-2 IBM 5-3 HDS 5-5 HP 5-6 ADTX 5-7. Contents v Cisco Data Center Interoperability Support Matrix . HDS-NetApp Enterprise gFiler NAS Gateways 15 Unisys - Microsoft Data Center 16 IBM Distance Extension 17 ESS 2105 model 800 18 .
Interoperability does not mean the same thing in every context. Interoperability is not always good for everyone all the time. And the relationship between interoperability and innovation, while it likely exists in most cases, is extremely hard to prove. There is no one-size-fits-all way to achieve interoperability in the ICT context.
instead of interoperability. But the old way of "stitching it together" doesn't work anymore. Enter interoperability. What does interoperability really mean for you? This book was written to help explain exactly that. Health information integration and interoperability aren't just for IT departments, CIOs, and informatics people anymore.
