Communications On The Move Using the Systems Decision Process to Assess Information Assurance Architectures Prepared by Cadet Chris Albornoz Cadet Zachary Fenn Cadet Blair Van Horn Cadet William Small Under the direction of Dr. Gregory S. Parnell Department of Systems Engineering United States Military Academy 05 April 2010 1 With the increases in technology available to our adversaries, the United States has had to adapt in order meet the changes in the war on terror and threats abroad. The two missions of the National Security Agency (NSA) “are to protect U.S. national security systems and to produce foreign signals intelligence information.” (www.nsa.gov) There are two different techniques that the NSA deploys in order to meet the challenges of the technological war that is currently underway: Information Assurance operations and Signals Intelligence operations. Our focus is on the Information Assurance mission, which “confronts the formidable challenge of preventing foreign adversaries from gaining access to sensitive or classified national security information.” (www.nsa.gov) This mission is essentially to prevent enemies of the United States from conducting successful signal intelligence operations against us. For this project, we are focusing on one of the Department of Defense’s latest acquisition projects: Communications On The Move (COTM). Specifically, we are analyzing the Information Assurance (IA) architecture of COTM. The COTM architectures of the military services are defined in the Government Reference Architecture. The objectives of the GRA are: Define a secure modular MILSATCOM terminal architecture Apply the Modular Open System Architecture (MOSA) Provide executable models and GRA companion documentation Enable life cycle cost and risk reduction With COTM, the Army is planning on using satellite communications (SATCOM) to provide secure communications during movement. When using SATCOM, there are several threats that are involved. These threats include jamming, unauthorized use, detection and interception, and nuclear effects. The COTM must meet multiple IA challenges all the while allowing platoon 2 level leaders in combat to securely operate their satellite terminal. These challenges include denial of service, assured startup, intrusion detection, being compromised, control and data separation. NSA and the Lincoln Laboratory at the Massachusetts Institute of Technology are helping to develop a secure architecture to overcome these threats, and it is our goal to assess this architecture and provide insight as to how to improve it as the COTM project progresses. In order to assess the architecture being developed for COTM, we will utilize the Systems Decision-making Process (SDP) designed by the USMA Department of Systems Engineering. The SDP, seen in Figure 1 is an iterative process that is composed of four major steps: problem definition, solution design, decision making, and solution implementation. Figure 1: Systems Decision-making Process The first portion, problem definition, is arguably the most important because all of the work done in this part of the SDP carries through the rest of the process. Poor problem definition will lead 3 to the design and implementation of a solution that may not solve the problem at hand, and as such our group dedicated most of the time allotted for this project to accurate problem definition. Problem definition requires a systems engineer to figure out what all of the stakeholders in a project want, need, and must have. Through stakeholder analysis, which involved many interviews, questionnaires, and teleconferences with our clients at the NSA, MIT, and the Army, we were able to piece together what IA functions COTM must perform and the objectives within these functions that it would achieve. An amalgamation of the Government Reference Architecture, a baseline architecture for all government satellite terminals, the Unclassified Information Assurance Security Requirements Document (UIASRD) produced by the NSA, and our stakeholder analysis, we were able to apply to each function and objective a quantifiable value measure that would ultimately be scored in order to assess the architecture in place currently. In order to score the architecture, each value measure requires a function to describe it so that different scores for each value measure translate to a portion of the overall score of the architecture. Once again, we utilized our stakeholders who were able to tell us viable ranges for each value measure and a mathematical function that described the magnitude of value change as scores rose or fell. Value measures are not all equally important, nor do some value measures affect the system as often as others, so it is important to weight the value measures in order to reflect their importance and variability. The SDP solves this weighting issue with a swing weight matrix, which organizes value measures by their importance on one axis and their variability on the other. Value measures with high importance and high variability receive larger weights than those with lower importance and or variability, and these weights are then multiplied by the 4 scores an architecture receives in each value function to compute that value measure’s total score for the architecture. Our group has just recently finished gathering the value scores from our clients at the NSA and MIT and are currently in the process of verifying these scores between the two stakeholder groups so that we may score the architecture. Once a score has been determined we will move into the solution design phase of the SDP. This phase involves recognizing the strengths and weaknesses of the architecture according to its scores and designing alternate solutions to the one that already exists. Many times this involves augmenting the existing design or mixing and matching the best parts of a few designs, but can also include building a completely new design. Considering the work that has been done thus far on COTM and the limits that the stringent requirements of the project set, it is likely that we will simply be identifying areas for improvement for COTM as opposed to designing a new alternate solution. The next phase to follow solution design is decision making. In this phase, the alternatives that have been generated as possible solutions are all compared and subjected to modeling and simulations if possible. In this phase, any uncertainty within value measure scores is tested through statistical analysis and simulations are built to determine which alternatives outperform the others under particular conditions. Our group should be able to build alternatives with our stakeholders and subject them to these tests in short order once scores are finalized. Once a superior alternative is identified, it must be implemented. The final phase of the SDP is the implementation of the solution that has been decided upon by the stakeholders following the alternatives’ analysis. This phase generally includes planning for controls and further assessments of the system as it is implemented and operated as 5 well as scheduling and work breakdowns that facilitate efficient implementation. This phase goes beyond the scope of our project as the implementation of a complex system such as this is very complicated and time consuming considering the technical aspects of SATCOM systems and the bureaucracy involved with government acquisition projects. We believe that the information we are able to provide to our stakeholders through our analyses and solution designs will be of great benefit to them, as implementing a system such as this is a process with which they are already very familiar. The contribution this project will make to the world of information assurance is that it will give one of the major players in information assurance, the NSA, a better method for decision making when designing information assurance architectures for future government acquisitions. The clients we have been working with are mostly higher level project managers, and by giving them experience with the SDP we hope that they will introduce this system to their organizations for implementation at the levels below theirs in order to optimize their organizations’ methods for decision making.