Fenn - Virginia Modeling, Analysis & Simulation Center

advertisement
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.
Download