An Architecture for Agile Systems Engineering of Secure Commercial-off-the-Shelf Mobile Communications
by Jamieson W. Gump
BS in Electrical Engineering, May 1984, University of Vermont MS in Engineering Management, October 1990, Western New England University
A Dissertation submitted to
The Faculty of The School of Engineering and Applied Science of The George Washington University in partial satisfaction of the requirements for the degree of Doctor of Philosophy
May 21, 2017
Dissertation directed by
Shahram Sarkani Professor of Engineering Management & Systems Engineering
Thomas A. Mazzuchi Professor of Engineering Management & Systems Engineering
The School of Engineering and Applied Science of The George Washington
University certifies that Jamieson Wesley Gump has passed the Final Examination for the degree of Doctor of Philosophy as of March 17, 2017. This is the final and approved form of the dissertation.
An Architecture for Agile Systems Engineering of Secure Commercial-off-the-Shelf Mobile Communications
Jamieson Wesley Gump
Dissertation Research Committee:
Shahram Sarkani, Professor of Engineering Management & Systems Engineering, Dissertation Co-Director
Thomas Mazzuchi, Professor of Engineering Management & Systems Engineering, Dissertation Co-Director
E. Lile Murphree, Professor Emeritus of Engineering Management and Systems Engineering, Committee Member
Bill A. Olson, Professorial Lecturer in Engineering Management and System Engineering, Committee Member
Paul L. Blessner, Professorial Lecturer in Engineering Management and Systems Engineering, Committee Member
ii
© Copyright 2017 by Jamieson Wesley Gump All rights reserved
iii
Dedication
This dissertation is dedicated to my patient and outrageously loving and supportive wife, Cheryl (Colburn) Gump.
iv
Acknowledgements
I would like to thank all the folks who helped me through this process.
I would like to thank my advisors for providing expert advice and for their
encouragement and humor. Dr. Shahram Sarkani and Dr. Thomas Mazzuchi were expert
advisors and helped dozens of students through the process with compassion and
wisdom.
For my colleagues at the Johns Hopkins University Applied Physics Laboratory
(JHU/APL) who work in this field with me and assisted with case study write-ups to
assist in the refining of my architecture. They are in the trenches with me working on
secure mobile for our critical U.S. Government users and have helped realize the vision
that the National Security Agency provided within the CSfC program. I want to thank
NSA: their vision and direction provided a foundation for this architecture framework.
I want to thank the folks that completed the case study questionnaires. These systems
engineers are all senior folks working on challenges projects for national defense.
I would like to thank the attendees at NDIA Systems Engineering Conference and the anonymous reviewers at the INCOSE Systems Engineering Journal for recommendations on my journal article.
Finally, I would like to thank the members of my George Washington University
Engineering Management and Systems Engineering (GWU EMSE) cohort for sharing lessons learned, strategies, and camaraderie through the process. In particular, my cohort
included colleagues at JHU APL, Matt Montoya, and Alan Ravitz. They went above and
beyond to share their thoughts during the process.
v
Abstract
An Architecture for Agile Systems Engineering of Secure Commercial-off-the-Shelf Mobile Communications
The United States (U.S.) Federal Government has long had a need for highly secure communications. The National Security Agency (NSA) is responsible for the wide range of technologies to secure these communications. They realized, recently, that the development times for U.S. Government encryption technology was not keeping pace with the rapid evolution of commercial mobile technologies coupled with a realization that commercial technologies exist to meet the requirements for the U. S. federal
Government. Specifically, NSA has published specifications on their website to operationalize these capabilities. Commercial Solutions for Classified (CSfC), the NSA term for Commercial Off-the-Shelf (COTS) secure communications, coupled with published capability packages allows a developer to rapidly field a secure communications solution built entirely on COTS technology. The end user is presented with the latest in mobile communications technologies with the software security applied after market. The first users of this technology are within the Department of Defense
(DoD); other agencies are anticipated to field capabilities as well. No architecture exists to aid in the development of these capabilities, and research is required to develop an overarching architecture to support these emerging capabilities. This architecture will address the rapidly evolving commercial mobile security market and address fully leveraging commercial technologies to field the latest technologies in the shortest amount of time and at the lowest cost. With the encryption built on software (vice hardware),
Agile Engineering techniques can be readily applied. Although developed in the U.S) for
viii
the U.S. Federal Government, this approach has been adopted by other governments and
is anticipated to be adopted by commercial users for enhanced security. With the NSA
move to commercial technologies and the commercial market moving to enhanced
security for “standard commercial users,” there is an emerging convergence of these two
approaches. An architectural construct to support this growing user base is the focus of
this research. The method to be employed is to survey the wide range of implementations
currently being fielded using a case study methodology, developing an effective
overarching architectural contract, and returning to the Subject Matter Experts (SMEs)
across this community to validate the architecture. The utility of the architecture will be
rooted in the ability to aid the full range of customers; from mobile phone solutions, to
secure laptops, and fixed communications at remote sites. The initial work has revealed
effective architectural constructs to support the wide range of emerging applications of
this promising approach from NSA – commercial solutions for classified.
Note: A shorter version of this work was accepted for publication as a journal article in Systems Engineering. (Gump, Mazzuchi, & Sarkani, 2017) and as a journal article in
Journal of Enterprise Architecture (Gump, Mazzuchi, & Sarkani, 2017).
.
ix
Table of Contents
Dedication ...... iv Acknowledgements ...... v Abstract ...... viii List of Figures ...... xiii List of Tables ...... xv
Chapter 1 - Introduction ...... 1 1.1 Research Problem ...... 1 1.2 Research Overview ...... 2 1.3 Overview of Dissertation ...... 3 Chapter 2 - Literature Review ...... 5 2.1 Mobility Introduction ...... 6 2.2 Introduction to Threats to Mobile Technology ...... 8 2.3 Mobile Enabling Technologies ...... 9 2.3.1 Wireless ...... 9 2.3.2 Commercial LTE and Vulnerabilities ...... 11 2.3.3 Public Key Infrastructure (PKI) ...... 12 2.3.4 VOIP Secure Calls ...... 12 2.3.5 Networking ...... 13 2.3.6 Mobile and Cloud Services ...... 13 2.3.7 Smart Grid...... 15 2.3.8 Near Field Capabilities (NFC) ...... 15 2.3.9 Virtual Private Networking (VPN) ...... 16 2.3.10 Mobile Applications ...... 16 2.3.11 U.S. Government Programs Supporting Mobility ...... 18 2.3.12 National Information Assurance Partnership Program (NIAPP) ...... 19 2.3.13 National Institute of Standards and Technology ...... 19 2.3.14 Commercial Solutions for Classified Program ...... 20 2.4 Mobile Security ...... 27
x
2.4.1 Mobile Security (General)...... 27 2.4.2 Mobile and User Satisfaction ...... 30 2.4.3 Commercial Mobile Applied to Tactical Comms ...... 30 2.4.4 Security Monitoring ...... 32 2.4.5 Mobile Operating Systems ...... 33 2.4.6 Android and Security ...... 34 2.4.7 Cryptography ...... 34 2.4.8 Mobile Trust Module ...... 36 2.5 Mobile Security Perspectives ...... 37 2.5.1 Mobile Security within the U.S. Federal Government ...... 37 2.5.2 NSA Perspectives ...... 38 2.5.3 DoD CIO Perspective ...... 41 2.5.4 Military Services and Joint Perspectives ...... 42 2.5.5 Coalition Warfare ...... 43 2.5.6 NATO Perspectives ...... 44 2.5.7 Department of Homeland Security Perspective ...... 46 2.5.8 Department of Energy Perspective ...... 46 2.6 Integration Strategies ...... 47 2.6.1 COTS Integration Strategies ...... 47 2.6.2 Agile Development ...... 51 2.7 Systems Engineering of Architectures ...... 54 2.8 Mobile and Legal Issues (and Privacy) ...... 60 2.9 CSfC Vendor Applications/Solutions...... 61 2.10 Conclusions ...... 64 Chapter 3 - Research Framework ...... 65 3.1 Research Gap ...... 65 3.2 Research Objectives and Questions ...... 67 Chapter 4 - Research Methodology ...... 69 4.1 Research Methodology Overview ...... 69 4.1.1 Strengths and Weaknesses ...... 78 4.1.2 Extensibility ...... 79 xi
4.2 Case Study Data Collection Questionnaire ...... 80 4.3 Case Study Characteristics ...... 80 4.4 CSfC Compliance Crosswalk ...... 84 Chapter 5 - Research Findings ...... 85 5.1 Initial Architecture Framework ...... 85 5.2 Final Architecture Framework ...... 100 5.3 Lessons Learned from Case Studies ...... 103 5.4 Architecture Framework Implementation ...... 110 5.5 Architecture Flexibility...... 112 5.6 Conclusions to Research Objectives and Questions ...... 116 Chapter 6 - Conclusions ...... 119 6.1 Overview of Research, Results, and Benefits ...... 119 6.2 Limitations ...... 123 6.3 Future Research ...... 124 Appendix A References ...... A-1 Appendix B Case Study Questions ...... B-1 Appendix C CSfC Compliance Crosswalk Tool ...... C-1 Appendix D Templates (Reference Architecture) for Final Architecture ...... D-1
xii
List of Figures
Figure 2-1 Research Focus...... 5
Figure 2-2 Parsed Dissertation Title ...... 6
Figure 2-3 Wireless Technology Roadmap (Raychaudhuri & Mandayam, 2012) ...... 10
Figure 2-4 SIP (and SIP with proxy) Overview (Lago-Fernández et al, 2014, p. 598) ... 13
Figure 2-5 NFC Contrasted with other Wireless (Kiehl & God, 2013, p2) ...... 16
Figure 2-6 Framework for Mobile Aps (Federal CIO Adoption of Mobile Aps, 2013,
p6) ...... 17
Figure 2-7 Mobile Applications Lifecycle Framework (Federal CIO Adoption of
Mobile Aps, 2013, p9) ...... 18
Figure 2-8 Three Layers of Standards ...... 18
Figure 2-9 New Paradigm for Encryption "Devices" (derived from NSA MACP) ...... 21
Figure 2-10 Spectrum of End-User-Devices...... 23
Figure 2-11 Formal Risk Model (Martinez & Haverkos, 2015, p9) ...... 25
Figure 2-12 Risk Model (Zage et al., 2015, p15)...... 26
Figure 2-13 Mobile Security Reference Model (MSRA, 2013, p5) ...... 38
Figure 2-14 DoD/VA IEPRA (DoD, 2015, p1) ...... 56
Figure 2-15 Conceptual Reference Architecture: IoT (Gamez, Fuentes, & Troya, 2015, p110) ...... 57
Figure 2-16 Mobile SOA Reference Architecture (Sefid-Dashti & Habibi, 2014, p414) 59
Figure 4-1 Systems Engineering “Vee Model” (Stevens, 1998) ...... 70
Figure 4-2 Systems Engineering “Vee Model” (Stevens, 1998) Applied to Architecture
Development ...... 70 xiii
Figure 4-3 Architecture Development Methodology ...... 72
Figure 4-4 Focus areas for Case Studies ...... 83
Figure 5-1 "Combination Lock" Analogy ...... 86
Figure 5-2 Architecture Framework ...... 86
Figure 5-3 High Level Requirements ...... 89
Figure 5-4 Policy Framework ...... 90
Figure 5-5 Risk Profile...... 90
Figure 5-6 Priority Service Issue ...... 92
Figure 5-7 Operating Locations Required ...... 93
Figure 5-8 A Sampling of Transport Alternatives ...... 94
Figure 5-9 DoDAF Based Secure Mobile Architecture ...... 101
Figure 5-10 Early Adopters Support Architecture Development ...... 111
Figure 5-11: Simplified Architecture Hierarchy ...... 113
Figure 5-12: RAs in Support of Secure Mobile ...... 116
Figure C- 1 Components List (Example) from NSA Site ...... C-2
Figure C- 2 MACP Configuration (from NSA) ...... C-2
Figure C- 3 Screen Capture of Compliance Tool ...... C-3
xiv
List of Tables
Table 2-1 Mobile Operating Systems Summary (Oberheide & Jahanian, 2010, p4) ...... 33
Table 2-2 Threats and Risk (Väisänen, 2015, p28) ...... 45
Table 2-3 COTS advantages and disadvantages (Boehm & Abts, 1999, p136) ...... 50
Table 2-4 COTS Assessment Attributes (Abts, Boehm, & Clark, 2000, p6) ...... 51
Table 2-5 Agile Factors (Eng, 2014, p30) ...... 53
Table 2-6 Types of contemporary Enterprise Architecture (EA) frameworks (Singh, Mudholkar, & Balani, 2015, p3) ...... 57
xv
List of Acronyms
Acronym Description
ACM Association for Computing Machinery AES Advanced Encryption Standard AFCEA Armed Forces Communications and Electronics Association AGATE Atelier de Gestion de l'ArchiTEcture (French) AO Authorizing Official App Application ARCON A Reference architecture for COllaborative Networks ASSIMPLER Availability, Scalability, Security, Interoperability, Availability, Scalability, Security, Interoperability, Extendibility, and Reliability ATO Authority-to-Operate BYOD Bring Your Own Device C&A Certification and Accreditation CAC Common Access Card CCI Controlled Cryptographic Item CCL CSfC Components List CDS Cross Domain Solution CIO Chief Information Officer CMDIP Commercial Mobile Device Implementation Plan CMM Capability Maturity Model CNSS Committee on National Security Systems COCOTS COnstructive COTS COMSEC Communications Security CONOP Concept of Operations CONUS Continental U.S. COTS Commercial Off-the-Shelf CP Capability Package CSfC Commercial Solutions for Classified DAR Data at Rest DDoS Distributed Denial of Service DGA France DGA Architecture Framework DHS Department of Homeland Security DISA Defense Information Services Agency DLP Data Leak Prevention DMCC Defense Mobility Classified Capability DoD Department of Defense DoDAF Department of Defense Architecture Framework DOE Department of Energy DOS Department of State DRSN Defense Red Switch Network DTIC Defense Technical Information Center
xvi
DYA DYnamic enterprise Architecture EA Enterprise architecture EACOE Enterprise Architecture Center of Excellence ECC Elliptic Curve Certificates ECSA European Conference on Software Architecture EMM Enterprise Mobile Management EMSE Engineering Management and Systems Engineering ERP Enterprise Resource Planning ESAAF European Space Agency Architectural Framework ESCOM-SCOPE European Software Cost Estimation Conference EST Enterprise System Topology EUD End User Device FAQ Frequently Asked Questions FBCA Federal Bridge Certification Authority FCS Foundation of Computer Science FDIC Federal Deposit Insurance Corporation FEA FDIC Enterprise Architecture FEAF Federal Enterprise Architecture Framework GD General Dynamics GEA Government Enterprise Architecture GERAM Generalized Enterprise Reference Architecture and Methodology GFDL GNU Free Documentation License GOTS Government Off-the-Shelf GPL Government Purpose License GRA Government Reference Architecture GWU George Washington University HSDN Homeland Security Data Network IA Information Assurance IAD Information Assurance Directorate IAF Integrated Architecture Framework IAS Information Assurance Specialist IATO Interim ATO IAW In Accordance With ICAIM International Conference on Advancement in IT and Management ICCRTS International Command and Control Research and Technology Symposium ICT Information and Communications Technology IDEAS International Defence Enterprise Architecture Specification IDS Intrusion Detection Systems IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers IEPRA Integrated Enterprise Portal Reference Architecture IFIP International Federation for Information Processing IFW Information FrameWork xvii
IJCA International Journal of Computer Applications IJCNIS International Journal of Communication Networks and Information Security IJLM The International Journal of Logistics Management IJMECS International Journal of Modern Education and Computer Science IJR International Journal of Research IMS Information Management Services INCOS Intelligent Networking and Collaborative Systems INCOSE International Council on Systems Engineering IoT Internet of Things IP Internet Protocol IPV6 Internet Protocol Version 6 ISO International Standards Organization ISPAB Information Security and Privacy Advisory Board ISR Intelligence, Surveillance, and Reconnaissance IT Information Technology ITAA International Trial Attorneys Association ITU International Telecommunications Union JFQ Joint Force Quarterly JHU/APL The Johns Hopkins University Applied Physics Laboratory JNCET Journal of Network Communications and Emerging Technologies JWICS Joint Worldwide Intelligence Communications System KG Key Generator LCN Local Computer Networks LEAD Layered Enterprise Architecture Development LTE Long Term Evolution LZ Landing Zone MACP Mobile Access Capability Package MAGTF Marine Air-Ground Task Force MBSE Model-Based Systems Engineering MDM Mobile Device Manager MEGAF MEGamodeling Architecture Frameworks MILCOM Military Communications MLS Multi-Level Security MODAF Ministry of Defence Architecture Framework MPLS Multiprotocol Label Switching MSA Mobile Security Architecture MSRA Mobile Security Reference Architecture NAF NATO Architecture Framework NASA National Aeronautics and Space Administrative NATO North Atlantic Treaty Organization NCW Network Centric Warfare NDIA National Defense Industrial Association xviii
NDSS Network and Distributed System Security NFC Near Field Capabilities NIAP National Information Assurance Partnership NIAPP National Information Assurance Partnership Program NIPRNet Non-Secure Internet Protocol Network NIST National Institute of Standards and Technology NSA National Security Agency NY New York OBASHI Ownership, Business Processes, Applications, Systems, Hardware, and Infrastructure OCONUS Outside CONUS ONR Office of Naval Research OPM Office of Personnel Management OPNET Operational Networks OS Operating System OWA Outlook Web Application PESQ Perceptual Evaluation of Speech Quality PIN Personal Identification Numbers PIV Personal Identity Verification PKI Public Key Infrastructure PV Project Viewpoint QOS Quality of Service R&D Research and Development RA Research RAMS Reference Architecture for Mobile Security RMF Risk Management Framework RM-ODP Reference Model of Open Distributed Processing ROI Return-on-Investment SABSA Sherwood Applied Business Security Architecture SAP Systems Applications Products SATCOM Satellite Communications SCI Special Compartmented Information SCIF Special Compartmented Information Facility SCIP Security Communications Interoperability Protocol SCRM Supply Chain Risk Management SECaaS Security as a Service SEI Software Engineering Institute SIM Subscriber Identity Module SIP Session Initiation Protocol SIPRNet Secret Internet Protocol Router Network SLA Service Level Agreement SMA Secure Mobile Architecture SME Subject Matter Experts SME PED Secure Mobile Environment Portable Electronic Device SOA Service Oriented Architecture xix
SP Special Publication SSL Secure Sockets Layer SSO Single Sign-on STC Software Technology Conference STEW Small Tactical Executive WAN TOGAF The Open Group Architecture Framework TS Top Secret U.S. United States UCR Unified Capability Requirements UK United Kingdom UML Unified Modeling Language UMLsec UML Security USG U.S. Government USMC U.S. Marine Corps VA Virginia VA Veterans Affairs VDI Virtual Desktop Infrastructure VM Virtual Machine VOIP Voice Over Internet Protocol VOLTE Voice Over LTE VPN Virtual Private Networking VTC Video Tele Conference WICSA Working IEEE/IFIP (International Federation for Information Processing) Conference on Software Architecture Wi-Fi Wireless Fidelity WPS Wireless Priority Service WRATH Wireless Remote Authenticated Tactical Handheld WSJ The Wall Street Journal
xx
Glossary of Terms
Architecture Definition Process – Is to generate architectural alternatives and select an alternative that addresses stakeholder concerns and meets the end-system requirements
(INCOSE Systems Engineering Handbook). These should be expressed in a consistent way and, if possible, guided by an architecture Framework(s).
Architecture Framework – Overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate the ability of managers at all levels to make key decisions more effectively through organized information sharing
(DoD, DoDAF, 2015).
Commercial-off-the-Shelf (COTS) – These products are developed by vendors on speculation of sale as contrasted by Government-off the-Shelf (GOTS), which are products that have been developed under a United States Government (USG) contract.
The magnitude of commercial sales is usually far greater than the USG, and this drives investments in research (funded by industry) and can reduce the end-item cost.
Grey – Used with Red (un-encrypted) and Black (encrypted). Grey is between Red and Black and contains one layer of encryption. According to the National Security
Agency (NSA), the Grey network should be protected as if it were at the level of the Red network.
Mobile Communications – Mobile are communications that support users on the move. They can range from mobile smart phones to tablets and laptops. The technology challenges with smaller devices are greater due to the limitations in compute power, battery life and other readily apparent constraints with a small mobile device.
xxi
Models – These are used to visualize architectural data. “Models can be documents, spreadsheets, dashboards, or other graphical representations and serve as a template for organizing and displaying data in a more easily understood format” (DoD, DoDAF,
2015).
Secure Communications – Communications that are protected from intercept. This
protection can range from nominal protection through protection that is enabled by the
highest levels that technology can now afford. No techniques exist for fully assured communications: with enough time all encryption can be broken. USG users are required to use “secure communications” for the transmission of classified information (For
Official Use Only, Secret, etc.). The USG provides guidance for level of security required (application of technology) to support the level of classification of the information being transmitted.
View – These are models populated (with data). They are organized under a viewpoint perspective. (DoD, DoDAF, 2015).
Viewpoint - Is a collection of views representing a perspective (or “viewpoint”).
These can represent systems, services, standards, etc. (DoD, DoDAF, 2015).
xxii
Chapter 1 - Introduction
1.1 Research Problem
Mobile phones were just becoming common place when the National Security
Agency (NSA) began the development of a mobile phone capable of making a classified
call. This phone included United States (U.S.) Government (USG)-developed encryption
hardware and took many years to develop. Once fielded, it was already obsolete. Over
time, commercial encryption technology matured for a range of markets and NSA began
to realize that a fully commercial, encrypted cell phone was practical, cost effective, and secure. This program, Commercial Solutions for Classified (CSfC) is emerging as a practical solution for a wide range of applications [Boyle, 2014; Buibish, Johnson, Emery
and Prudlow 2011; Landau, 2014; LeMaster, 2013; Murphy et al., 2013; Plunkett, 2014;
Rasmussen, 2012; Roper, Ziring and Neal, 2012]. NSA has developed a range of
“capability packages” (Campus Wi-Fi, Mobile Access, etc.) that provide guidance for the development of these capabilities. This research extends this guidance to form a
comprehensive architectural framework and reference architecture for the integration of a wide range of applications.
With the expansion of mobile technology and increased awareness of security concerns [Bailey, 2014; Becher, et al., 2011; Leavitt, 2011; Li and Clark, 2013;
Oberheide and Jahanian, 2010], this architecture provides a framework to support this transformative technology. Current applications include secure mobile phones built from commercial mobile phones from Motorola, Samsung, and Boeing that are just now being fielded. Future applications of CSfC applications could include
1
communications devices that are used across the globe. One unique aspect of these
devices is they are paired with a “landing zone” (LZ) (where communications traffic is
“landed” in the enterprise infrastructure), and if a device becomes lost or stolen, it has
limited utility and can be readily denied access to the network. The strict pairing
between the device and its associated LZ facilitates this removal of devices from the
network. With this approach, a direct call between phones is currently not supported;
the LZ is required. In addition, in the past, the commercial device was considered a
Controlled Cryptographic Item (CCI) and involved risk as the compromise of the CCI
technology would impact the enterprise. With a pure commercial development, the
technology is already well known and is in the public domain.
With the move to commercial integration coupled with the CSfC approach and the
integration with legacy devices, an architecture that facilitates the development of
solutions for the full range of users from USG to industry (banking, law-enforcement,
etc.) supports the systems engineering required for the development of these
transformative applications for both mobile and fixed communications (at remote sites).
1.2 Research Overview
In this research, I developed generalized architecture framework for secure mobile communications using commercial technology. As this is an emerging capability to support the most critical level of communications, there is early open source direction
from NSA, but there is no comprehensive architecture to support the implementation of
solutions. The research objectives include developing this architecture using systems
engineering methods and incorporating a wide range of supporting technologies. A
review of the literature for both the enabling technologies as well as published literature 2
on solutions and relevant issues surrounding secure mobile was accomplished. The
architecture framework was developed and verified and validated using a systems
engineering approach supported by case studies collected from early adopters of this
strategy for secure mobile communications. I developed a validation tool to demonstrate
a cross walk between the selected hardware in a composed solution and the direction
from NSA (recommended CSfC Components List).
Initial requirements were re-validated and the final architecture was reviewed against
the latest literature on this topic to ensure the most current thinking on this emerging
capability was addressed in the research.
1.3 Overview of Dissertation
I organized this dissertation as follows. Chapter 1 (this chapter) provides for an
introduction of the dissertation. Chapter 2 contains an overview of relevant literature to
address the problem and approach introduced in this chapter. The literature review
begins with an introduction to mobile technology and is followed by the threats to mobile
(motivation for security solutions more fully explored), enabling technology, and mobile
security (strategies). The literature review continues with perspectives from various stakeholders, integration strategies with a focus on commercial off-the-shelf (COTS) integration, systems engineering, mobile legal issues and finally a brief review of vendor solutions developed in this space.
In Chapter 3, I discuss the gaps in research framed by the literature review within
Chapter 2. With an emerging capability there are gaps by nature of the “newness” of the approach. The secure mobile based on CSfC is an innovative strategy to meeting the
3
end-user requirements. The research topic is more fully explored with a discussion of the
specific objectives and research questions being identified.
In Chapter 4, I discuss addresses the research methodology employed in this research.
The methodology is reviewed as a high-level construct incorporating the systems-
engineering paradigm followed by a detailed step-by-step review of the methodology
employed for this study. Case study research was discussed and its contribution to the
research.
Chapter 5, I describe the architecture and the evolution of the framework. Lessons
learned from the case studies and incorporated into the architecture were reviewed. The
chapter ends with a review of the architectures contribution to the field.
In Chapter 6, I provide a conclusion and summarize areas for additional research.
The areas for additional research are organized around the literature review topics.
Four appendices are included A) References, B) Case Study Questions, C) CSfC
Compliance Cross Walk Tool, and D) Templates for the Final Reference Architecture.
4
Chapter 2 - Literature Review
A literature review for an architecture for commercial secure mobile communications involves an industry that is rapidly changing with a wide range of technologies required. This wide range of technologies is required by NSA to implement a highly secure mobile solution, and this literature review includes a review of the most critical of these technologies, addresses published USG strategies, and supports the architecture to realize an operational capability for a wide range of end- users. These users span from tactical users in the field to our most senior leaders. The recognition by the USG that their investment in these technologies cannot compare to the massive investments being made in the commercial sector has led to a strategy to leverage these technologies to achieve capabilities and evolve over time with the continuous advances in this field. The literature review focuses on the union of critical developments in a limited range of disciplines (Figure 2-1).
Figure 2-1 Research Focus
5 Parsing the dissertation title and summarizing the complete range and contrasting
with the research focus provided additional context and focus (Figure 2-2).
Figure 2-2 Parsed Dissertation Title
2.1 Mobility Introduction
Increasingly our workforce is expected to operate on the move and technology has increasingly enabled our mobile workforce. With the rapid changes in mobile technology it’s critical to understand the trends and plan strategies to incorporate these aspects of mobile technology in fielded solutions as well as to incorporate leading edge technologies in new capabilities being fielded. Mobile introduces unique challenges that must be understood by systems integrators and USG leaders fielding these capabilities. A wide range of literature discusses the expanding use of mobile communications for a wide range of applications. Mobile security is of particular concerns with the increased use of on-line banking as privacy concerns mount with daily scandals over intercepted financial communications.
Technology evolution coupled with the expanding mobile market place needs to be managed to field the latest secure mobile technology. Fitton, Sandler, and Badgett
6 (2012) in Mobility for Dummies focused on deployment of Enterprise Resource
Planning (ERP) applications to the mobile edge and briefly discuss the future of
mobility. The authors discuss the future trends with mobility:
"▶ Seeing how cloud services will grow
▶ Identifying how interaction with devices will increase
▶ Blurring the line between work and pleasure
▶ Living a wireless life" (page 69)
Much of the mobility forecasting includes broad technologies with limited discussion of the timelines or specific implementations, but for the researching (and integrator) these trends are important as they drive the marketplace (and development of supporting technologies. Gartner Mobile Top 10 (2014) explores the top ten emerging mobile trends. Of particular interest to secure mobile is the integration of a wide range of mobile management tools into a smaller set of Enterprise Mobile
Management (EMM) tools that integrate a range of functions to include security. For
CSfC based applications, a Mobile Device Management (MDM) is a requirement from
NSA. There are a range of management features that can be integrated to ease the
management of scores of mobile phones in the field. These EMM tools are still under
development, and vendor research for in this area is critical for the integrators at this
time.
Phunware (2013) compiles mobile statistics to include the fact that more than half
of all Americans have a smart phone. These statistics paint a clear picture of the
growth of the mobile market. Again, these statistics summarize both the market growth
7 and the specific trends (such as the growth of Android) which drive the marketplace
and product development that will be leveraged by CSfC deployments.
2.2 Introduction to Threats to Mobile Technology
With the expansion of mobile technology and the emerging cyber threat, an
understanding of the threats and mitigation strategies is critical for secure (classified)
communications. These technologies are rapidly changing with both the emerging
Information Technology (IT) markets and the growing threat. These threats will drive
product development in technologies such as hardware root of trust and other enabling
technologies that can be leveraged by CSfC applications.
Leavitt (2005) wrote of the malicious code threat to mobile devices when these
threats were just emerging. The specific threats have changed, but the author’s
discussion of the motivation and factors surrounding these security threats have
remained constant. Leavitt (2011) authored a follow-up piece that discussed the current
threats and the expanding threat to mobile devices. Understanding these threats is
important to engineering a resilient solution. CSfC provides minimum security
mechanisms and the each integrator is able to add additional security as the budget
allows and the operator demands.
Becher et al. (2011) provides a thorough review of the threats with smartphones.
The most likely considered these threats when designing the CSfC program. These
threats can be countered by the CSfC architecture coupled with a comprehensive
information assurance strategy when composing solutions. The threats discussed
within this paper can be viewed in conjunction with end-user requirements to develop a
solution that is both effective for the end user AND provides robust security for the
8 threats of today as well as the emerging threat vectors. Again, the research does not
discuss details of NSA threat and risk: this area of research was specifically avoided).
Dawson, Wright, and Omar (2015) explored the range of cyber vulnerabilities of standard phones. CSfC implementations share some of these same vulnerabilities. A conventional system view would evaluate each product (or component of the larger system) for security vulnerabilities and fails to view these components integrated into a larger construct such as a CSfC Landing Zone that can prescribed by the NSA in a capability package for end user implementation and fielding. The days of an
encryption device that has one red connection and another black [such as a Key
Generator (KG) device] are contrasted with the new paradigm under CSfC. An
awareness of these risks from standard phones should be tracked to provide early
identification of vulnerabilities. Specific identification of vulnerabilities are reserved
classified systems; refer to NSA risk assessments discussed on the CSfC page at NSA.
2.3 Mobile Enabling Technologies
Mobile leverages a range of critical technologies (from other applications) that must
be understood to develop advanced mobile solutions. The small form factor operating
over wireless connections drives with the very real possibility of loss of the device are
the top drivers. The consumer market is often unconcerned by the underlying
technology, but are increasingly purchasing these devices for the obvious convenience.
2.3.1 Wireless
Transport for the mobile user can range over all available wireless technology. The
technology has improved over time, and the diversity of technologies has increased.
When composing a solution, all available wireless technologies should be considered
9 and evaluated. Some wireless segments are combined with fixed communications
backhaul for improved connectivity. Some end-user devices can operate over multiple
wireless paths, i.e., mobile phones with long-term evolution (LTE) and Wi-Fi.
Wireless technologies vary with regards to inherent risk from a cyber-security perspective as well as the obvious operational differences such as range, accessibility, and other aspects.
Raychaudhuri & Mandayam (2012) developed a wireless technology roadmap
(Figure 2-3). This four layer model is helpful in understanding the evolution of the technology. Each system application can potentially be combined with multiple network technologies, etc. This quickly becomes a complex landscape that should be understood by integrators to develop the most capable solutions for the end-user.
Figure 2-3 Wireless Technology Roadmap (Raychaudhuri & Mandayam, 2012) Moses (2014) provided a summary of the evolution of mobile technology and specifically discusses vertical hand-overs. Handovers could support mobile users migrating across cells within a network and then seamlessly migrating to Wi-Fi. Moses
(2014) also recognized the importance of these emerging capabilities. For USG-secure 10 communications, hand over is a critical enabling technology. One could envision a user in a limo leaving the vehicle (Wi-Fi hot spot) and walking to a golf course (cellular) and never dropping the secure call.
2.3.2 Commercial LTE and Vulnerabilities
Cellular protocols are rapidly moving to LTE. CSfC solutions use standard cellular
(LTE) networks for commercial cellular transport. LTE is evolving and will impact the
performance of CSfC LTE solutions. An architecture for secure mobile must
incorporate LTE and evolve with the evolution of LTE. In addition, LTE introduces
vulnerabilities to secure mobile solutions.
QUALCOMM (2012) described the phases of LTE evolution from simultaneous
voice circuits with LTE data, to the emergence of voice-over LTE (VOLTE) to truly
converged services. CSfC utilizes encrypted Voice-Over Internet Protocol (VOIP) calls and, as such, already rides the LTE data path and not the voice circuits that are evolving. Similarly, the vision is for standard LTE cellular calls to move to VOIP
(data) calls and this will be transparent to the end-user. The CSfC calls need to be
VOIP calls to be encrypted even though there may be performance impacts with the
quality of service (QOS) as the carriers are unaware that the encrypted CSfC data
connection is actually carrying voice.
Clancy, Norton, and Lichtman (2013) discussed standard commercial LTE and the vulnerabilities with this technology. Secure communications using COTS leverages
LTE as the cellular transport so LTE vulnerabilities are important aspects of a comprehensive look at the threats to these composed solutions.
11 Smith et al. (2010) discussed techniques to secure standard commercial cellular traffic using technology that the carriers could readily deploy. Note that even if the carriers were to implement very high levels of security to ensure that USG users could not be intercepted, the traffic still traverses the unclassified terrestrial telephony. This is clearly not acceptable, but these techniques, layered with CSfC, can provide enhanced security for USG users.
2.3.3 Public Key Infrastructure (PKI)
An important aspect of CSfC implementations is incorporation of certificate-based authentication. To ensure cross-enterprise authentication of PKI infrastructure the U.S.
Federal Government established a Federal Bridge Certification Authority (FBCA). The
FBCA has published X.509 Certificate Policy (No. Version 2.27, 2014) that establishes a federal-wide certification standard. Federated bridge certificate authorities have not been fully implemented on unclassified networks and even less has been accomplished on the closed, classified networks. Additional standards and integration activities are required in this area.
2.3.4 VOIP Secure Calls
VOIP is rapidly replacing switched telephony. VOIP calls can be secured with a variety of techniques. VOIP is used to secure mobile calls using CSfC approach.
Therefore, understanding the advances in VOIP technology is import for a comprehensive CSfC solution.
Lago-Fernández et al. (2014) proposed techniques for secure VOIP calls. They introduced Session Initiation Protocol (SIP) (Figure 2-4 SIP (and SIP with proxy)
Overview (Lago-Fernández et al, 2014, p. 598)) as this is an enabling technology for
12 industry standard VOIP. Although Lago-Fernández’s et al. approach is not compliant
with NSA CSfC, it explores additional approaches.
Figure 2-4 SIP (and SIP with proxy) Overview (Lago-Fernández et al, 2014, p. 598)
2.3.5 Networking
When solutions land at the LZ, the enterprise traffic for voice, video, and data is
transmitted over networks, but the networks are outside the mobile solution.
Integration with existing networks is required to field a complete capability. Grayeli,
Sarkani, and Mazzuchi (2012) discussed Internet Protocol Version 6 (IPV6) and
Multiprotocol Label Switching (MPLS) for improved network performance. These
network architectures can be simulated or emulated using tools such as an Operational
Network (OPNET). Additionally, Grayeli, Sarkani, and Mazzuchi (2012) developed a
rigorous process of analysis using these network analysis tools and techniques. The
general methodology can be applied to a wide range of networking constructs.
2.3.6 Mobile and Cloud Services
Cloud technology allows for enhanced security since the device at rest contains no classified information since the classified information resides in a cloud. One clear disadvantage is no support for disconnected operations when operating on the cloud.
For some early implementations of CSfC solutions, while Data-at-Rest (DaR) solutions
13 are immature, there may be expanded use of cloud mail servers and access to other
classified data.
Joshi & Tikar (2015) proposed a four-layer cloud services model. Mobile devices
are envisioned to access the cloud services over a range of media. The authors posit the
following: “Security as a service (SECaaS) options are many and varied, and include
the following:
• Content security services such as spam and anti-malware filtering for e-mail (like
Google's Postini) and Web content filtering.
• Network security services such as firewall, intrusion detection, and prevention,
and distributed denial of service (DDoS) protection.
• Data leak prevention (DLP)
• Single sign-on (SSO)
• Log management and analysis” (page 139)
Joshi & Tikar (2015) discussed Bring Your Own Device (BYOD) and the
advantages of enterprise cloud services for hosting the corporate data that are then
provided to the end-user via these cloud services. BYOD has unique challenges. For example, the integration of personal devices with enterprise networks has legal/policy challenges in addition to technology challenges to safeguard the enterprise infrastructure from devices that have limited configuration management and cyber- protection. Many home users will download applications with little concern over the inherent risks.
Simanta et al. (2012) proposed cloudlets for "hostile environments." Environments such as disasters and combat zones need to leverage the power of cloud computing, but
14 often can't access the cloud. If a portion of the cloud (cloudlet) is pushed close to the
mobile edge, this hybrid architecture can take advantage of clouds without the issues
that come from disconnected operations.
2.3.7 Smart Grid
The electrical grid is increasingly being managed using commercial information technology. These technology enhancements are being referred to as the “smart grid.”
With automation of utilities and other new strategies the application of IT, there are
related emerging threats and concerns. Systems that were once stand-alone and thus inherently more secure are rapidly being added to the Internet and brought “on-line.”
Secure communications are required for these critical utility communications.
Mahmood, Javaid, & Razzaq (2015) explored techniques for wireless communications for smart grid. The authors examined a wide range of technologies from LTE to Wi-Fi and discussed security protocols to protect these communications.
Mobile communications for the smart grid relate directly to data communications for secure mobile. Secure mobile using CSfC are VOIP/data calls, and smart grid communications are data communications (machine-to-machine). Smart grid efforts should leverage secure mobile communications advances and vice versa.
2.3.8 Near Field Capabilities (NFC)
NFC has been proposed for a range of mobile phone applications to include hard certs. NFC is relatively new technology that is just now being explored for a range of applications.
Kiehl & God (2013) explored Near Field Capability (NFC) technologies for use on mobile phones and discussed a specific application within an aircraft cabin. The
15 authors began with an explanation and contrast of NFC with other technologies (Figure
2-5 NFC Contrasted with other Wireless (Kiehl & God, 2013, p2)). Kiehl & God
(2013) also provided a good use case for this emerging technology. The small form factor for NFC devices provides many operational advantages for systems integrators.
Figure 2-5 NFC Contrasted with other Wireless (Kiehl & God, 2013, p2)
2.3.9 Virtual Private Networking (VPN)
VPNs are a critical component of CSfC as at least one layer of security is accomplished by the VPN layer that is encrypted by Advanced Encryption Standards
(AES).
Rittenbach et al. (2013) proposed a USG Reference Architecture (GRA) for VPN networks. The VPN Capability Package (CSfC package) is not addressed, but the concepts have applicability to VPN Capability Package deployments. Various aspects of COTS integrations are discussed as well as lessons learned.
2.3.10 Mobile Applications
Mobile applications are envisioned as one component of a secure mobile solution, but, to date, limited developments of mobile applications for the classified environment have been developed. The millions of “mobile aps” on the unclassified consumer side
16 can’t just be lifted up to the classified side. Often federal/military applications have
unique requirements and the data sources are not always available on the classified
networks. A full mobile application ecosystem for secure mobile users is most likely
years away. Federal Chief Information Officer (CIO) Adoption of Mobile Aps (2013)
focused strategies for adoption of mobile applications. This paper proposed a
framework for the various types of mobile applications (Figure 2-6 Framework for
Mobile Aps (Federal CIO Adoption of Mobile Aps, 2013, p6)).
Figure 2-6 Framework for Mobile Aps (Federal CIO Adoption of Mobile Aps, 2013, p6) In addition, the authors (Federal CIO) developed a general life cycle framework
(Figure 2-7 Mobile Applications Lifecycle Framework (Federal CIO Adoption of
Mobile Aps, 2013, p9)).
17
Figure 2-7 Mobile Applications Lifecycle Framework (Federal CIO Adoption of Mobile Aps, 2013, p9)
2.3.11 U.S. Government Programs Supporting Mobility
As discussed, the USG recognizes the commercial firms working mobile solutions for the standard commercial markets are leading USG technology in this field, and there is an operational need to leverage these advanced technologies. Three critical
USG programs enable the development of these capabilities. The foundational program is to ensure cyber secure using the Risk Management Framework (RMF), mandated by
DoD, this program leverages work by the National Institute of Standards (NIST) that addresses security for the whole of the USG. The National Information Assurance
Partnership (NIAP) is a partnership between USG and industry to encourage industry to build in cyber security within commercial products. Finally, the CSfC programs address secure communications using commercial IT (Figure 2-8 Three Layers of
Standards). The NSA needs industry participation so program details are fully shared; however, implementation risk reports are only shared with USG users to support accreditation.
Figure 2-8 Three Layers of Standards
18 2.3.12 National Information Assurance Partnership Program (NIAPP)
The NSA has developed partnership with industry to publish protection profiles for their incorporation and validation while developing IT systems. The process improves the nation’s cyber resilience along a wide range of dimensions. CSfC solutions are composed from NIAP Program- (NIAPP)-validated products that are subsequently added to the CSfC approved products list.
Houck (2011) presented an overview of the NIAP at the Information Security and
Privacy Advisory Board (ISPAB). The NIAP process is more fully described at the
USG web site (https://www.niap-ccevs.org/pp/). The NIAP process encourages vendors to implement security mechanisms in products and conduct testing prior to product release. The cost is a burden on the developers, but these security requirements can be mandated for USG acquisitions and encouraged for commercial deployments.
The philosophy is greater security for the U.S.’s IT infrastructure.
The policy for NIAPP is contained within the Committee on National Security
Systems a9CNSSa0 Instruction No 11 (2013). Details for the NIAP program are contained within the NIAP site (https://www.niap-ccevs.org/pp/).
2.3.13 National Institute of Standards and Technology
The DoD certification and accreditation (C&A) process, now referred to as RMF, leveraged NIST standards. RMF is required for all DoD programs; therefore, making these NIST standards important for the implementation of a complete solution.
NIST created the NIST Special Publication (SP) 800-53, “Recommended Security
Controls for Federal Information Systems and Organizations,” to establish a
19 standardized set of information security controls for use within the U.S. Federal
Government. CNSS Instruction No. 1253 (2012) is a companion to the NIST standard.
2.3.14 Commercial Solutions for Classified Program
The CSfC Website (https://www.nsa.gov/ia/programs/csfc_program/) is the
"official" CSfC web site for the NSA to distribute program information. In addition,
they ask that USG officials implementing secure solutions reach out to the NSA for
additional documentation. In particular, the risk assessments are classified and need to
be distributed on a Secure Internet Protocol Network SIPRNet or Homeland Security
Data Network (HSDN), etc. - classified e-mail.
NSA developed an early pilot (Fishbowl) in 2010 that proved out the approach.
Over the past five years, the pilot has been operationalized, and the core NSA
architecture has matured as described in the CSfC literature.
Some individuals familiar with traditional encryption devices struggle with the new
paradigm. A traditional encryption device encrypts red (plain text) to black (cypher
text). With a CSfC approach, a collection of commercial hardware and software
products are integrated to become a “virtual” encryption device (Figure 2-9 New
Paradigm for Encryption "Devices" (derived from NSA MACP)).
20
Figure 2-9 New Paradigm for Encryption "Devices" (derived from NSA MACP)
In 2012, the NSA began to publish details on the CSfC program on a public website. This program involves the integration of commercial technology from a wide range of vendors that can be readily facilitated by an open website. The public nature of the program supports researchers working in the expanding field. The CSfC program includes a range of applications from Virtual Private Networks (VPNs) to mobile access mechanisms. Each technology area is supported by a Capability Package (CP) that is published on the NSA public website. The Mobile Access Capability Package
(MACP) and the Data at Rest (DAR CP) [currently in draft], directly support the architectural framework proposed in this paper. The capability packages include enough specificity to aide integrators in the application of advanced systems engineering strategies for addressing cyber security concerns. As one example, vendor
21 diversity is a key aspect of cyber resilience [Jones & Horowitz, 2012], and the
capability package addresses this requirement. The capability packages form a
foundation for the reference architecture proposed.
The capability packages provide guidance for the minimum cyber resilience
elements in the system design, according to NSA. A methodical, standards based,
treatment of the problem can yield improved cyber resilience and integrators are
encouraged to consider additional security mechanisms. In particular, systems
engineering standards that address a standard systems engineering methodology integrated with security systems engineering [Evans et al., 2010] can provide an excellent framework for developing a strategy to layer in additional security features in the implemented solution.
The MACP addresses two primary components of the architecture: the End-User-
Device (EUD) and the LZ. The EUDs can be a wide range of devices (Figure 2-10
Spectrum of End-User-Devices). Clearly, a smart phone presents additional integration
challenges as the computing power of these devices is limited over a tablet. However,
the basic approach of using two layers of encryption (in software) applies to both
devices, and they can be supported by a common architecture.
22
Figure 2-10 Spectrum of End-User-Devices Once capability packages are defined, components are identified and added to the
CSfC Component List (CCL) using an NSA published approval process. When
composing solutions, care should be taken to select products on the CCL (when available).
The capability packages include enough specificity to aide integrators in the application of advanced systems engineering strategies for addressing cyber security concerns. As one example, vendor diversity is a key aspect of cyber resilience (Jones
& Horowitz, 2012) and the capability package addresses this requirement. The capability packages form a foundation for the reference architecture proposed.
The capability packages provide guidance for the minimum cyber resilience elements in the system design, according to NSA. A methodical, standards-based treatment of the problem can yield improved cyber resilience, and integrators are encouraged to consider additional security mechanisms. In particular, systems- engineering standards that address a standard systems-engineering methodology integrated with security systems engineering (Evans et al., 2010) can provide an
23 excellent framework for developing a strategy to layer in additional security features in the implemented solution.
Rasmussen (2012) discussed the emerging CSfC program to include the history and motivating factors. The author included a brief discussion of the policies lagging behind the implementations. As an example; can a Top Secret phone be used in a Top
Secret facility as standard mobile cell phones are not allowed? Rasmussen noted the process for application vetting lagging behind the networking, hardware, and other aspects of the end-user implementations. Rasmussen made a clear case for the needs for these technologies and provided an "insiders" perspective.
Le Master (2013) is a journalist for "The Modern Network" who wrote a piece on the CSfC program. This high-level overview, in addition to other published pieces in the press, helps NSA publicize the CSfC program and direct the readers to the official
NSA site.
Suder et al. (2015) recommended that a business model be developed to encourage vendors to participate in the CSfC program. A vendor is required to use NIAP approve devices and then follow up with a CSfC process with NSA. The vendors must make the investment to receive these "certifications," and many are not willing to make this investment. Thus, the authors recommend a business model that would capture Return- on-Investment (ROI) for vendors.
CSfC solutions recommend a layered strategy to achieve greater security. These layers should include diverse implementations such that a single failure of a device would not yield a compromise (belt and suspenders). Martinez and Haverkos (2015) developed a formal risk model (Figure 2-11) that attempts to develop a mathematical
24 model to determine overall system risk with a layered solution. Their work was
specifically accomplished to study CSfC architectures as proposed by NSA.
Figure 2-11 Formal Risk Model (Martinez & Haverkos, 2015, p9) Zage et al. (2015) were under contract to the NSA to develop a risk model for CSfC solutions. This model addresses the range of risks and attempts to quantify the risk along a range of dimensions (Figure 2-12 Risk Model (Zage et al., 2015, p15)).
25
Figure 2-12 Risk Model (Zage et al., 2015, p15) The NSA’s Roeper and Ziring (2012) described the CSfC program at a high level with a focus on strategies for enhanced security. Roeper and Ziring compares
Government-Off-the-Shelf (GOTS) and COTS; GOTS has a higher assurance life-cycle
COTS and USG control with a slow development cycle, contrasted by COTS with a variable assurance, lower cost and development time, and less USG control. The authors asserted that these security mechanisms have broad applicability beyond USG application. The development process was summarized as select standards, compose solution, select implementation (vendor components), and finally implement. A high- level process flow is proposed to support the CSfC development concepts presented within the CSfC program. Concepts of independence are discussed to support enhanced security the dimensions presented are Algorithmic, Credential, Codebase, and
Administrator. Roeper and Ziring proposed a layered independent protection construct with an associated mathematical model to quantify the protection improvements with security with additional layers. Roeper and Ziring discuss areas for additional work
26 more rigorous definitions of independence, addition of independence in certification
programs (such as NIAP), improved test strategies, and formal or scientific basis for
measuring confidence.
As commercial integrators, USG agencies and not-for-profits (such as University
Affiliated Research Centers) create complete integrated solutions these solutions are
being published in the current literature. Murphy et al. (2013) discussed one such
implementation known as Sharktank (a play on words from the NSA Fishbowl
program). The Sharktank implementation is described and the authors discussed the
issues remaining for these implements. There are signal strength issues with cellular,
supply chain issues, limited MDM products, cellular, or Wi-Fi (still difficult to do
both), and finally, a discussion of encryption overhead and impacts given limited
bandwidth.
2.4 Mobile Security
An architecture for secure mobile must support a range of users. Various USG
users have published requirements and perspectives that must be addressed to support
fully the diverse needs of these communities. As discussed, the integrators are required
to be award of the mobile security landscape and incorporate appropriate security
measures.
2.4.1 Mobile Security (General)
Braun and Danzeisen (2001) provided an early look at an architecture that is very similar to what NSA now mandates with the CSfC strategy. The authors conducted some performance testing using thorough quantitative testing down at the packet loss
27 level (and similar). With many implementations, the integrators should look at performance testing that is similar to what was presented in this paper.
Li and Clark (2013) explored mobile security and discussed various strategies to
secure these devices. They proposed "infrastructure-centric and multilayered security
schemes" (page 80) to address mobile security. Li and Clark (2013) also discussed the
risks with mobile devices and the challenges in securing these devices. They
recognized the compute limitations with mobile devices and explore feasible
alternatives.
Tang, Tsai, and Dong (2013) provided a constraint-based framework for mobile
computing. They discussed each constraint and summarized the mobile security
challenges. “In general, Enterprise mobile security includes the following core
functions:
• User authentication, including personal identity verification (PIV) card • Device, mobile app and enterprise services access control • Stored data encryption and end-to-end encryption for sensitive data, such as credit card • Application whitelist/blacklist • Content filtering and malware protection • Security event monitoring, logging, and response • Data leak protection & removable storage control” (page 28)
Bailey (2014) recognized the move to expanding mobile needs for end-users and proposes an "agile" approach to security. Bailey acknowledged the rapid development of secure mobile hardware and software and posited that an environment that can rapidly integrate new hardware and software into the architecture is a recommended construct. Furthermore, Bailey recommended supporting BYOD in the work force, but failed to address the detailed strategies to ensure enterprise security is maintained.
28 Aroucha et al. (2015) recognized the security vulnerabilities and proposed an
adaptive security mechanism leveraging commercial Secure Sockets Layer (SSL). The proposed approach aligns with the NSA CSfC, and this evolving industry and academic
work can be leveraged for CSfC approaches.
A hypervisor is software that manages virtual machines within a compute platform.
Mobile computers have enough compute power to host a hypervisor and run virtual machines. These implementations are power and compute intensive but offer security advantages and can be leveraged for mobile users within an USG (high security) application. Lim et al. (2015) proposed a secure hypervisor to isolate the processing to a VM that can clearly protect the mobile platform from compromise through a strategy of isolation of the virtual machine (VM). Additionally, Lim et al. proposed the following as primary security mechanisms: "Domain Separation, Secure File management, Secure Middleware, and Access Control" (page 1417).
Braga et al. (2015) discussed alternatives for both encrypted communications and secure (encrypted) storage of information on a mobile device. The authors explored a wide range of alternative implementations. Many of presented alternatives will be supported by the NIAPP and CSfC process/program, but some are not at this time. It is critical that the wide range of commercial alternatives be evaluated in light of current
USG direction for USG applications. If there are clear advantages to a recent commercial development, these technologies can be integrated, and the resulting solution more fully evaluated in terms of risk with the composed system.
29 2.4.2 Mobile and User Satisfaction
Many of these security features are required for secure (classified) communications,
but the user experience is important to device adoption and user satisfaction and should
be considered throughout the design and development process. Hasan et al. (2015)
explores the impacts of various security mechanisms on mobile user satisfaction. Other
researchers work in human factors engineering can provide valuable insight into
barriers to user adoption as well as user satisfaction.
2.4.3 Commercial Mobile Applied to Tactical Comms
CSfC solutions have predominantly been non-tactical applications with commercial
gear not well suited to a field or standard military environment. Commercial vendors
are increasingly developing ruggedized versions of commercial computers, phones, etc.
that could be applied to the tactical environment. An integration of commercial and
military grade electronics is envisioned that is both cost effective and reliable in a
tactical environment.
Buibish et al. (2011) discussed the issues surrounding secure smart phones within a
tactical environment. The authors incorrectly stated that CSfC only supports Secret and
below communications. In reality, the technology can support communications at the
TS/SCI level. Buibish et al. also addressed loss scenarios and risk mitigation techniques for the challenging tactical environment. In other words, if a phone is lost in
enemy lands, there are a large of number of issues compared to a loss in the continental
U.S.( CONUS).
Jousselme et al. (2013) developed a formalized construct for vulnerability in a tactical environment and proposed a novel approach of pattern-recognition as applied to
30 vulnerability assessment. This was applied to autonomous systems (robots), but clearly has broader applicability to more standard mobile solutions such as under the CSfC program.
Das et al. (2013) discussed tactical deployments of commercial LTE coupled with commercial Wi-Fi and CSfC solutions. The proposed architecture demonstrated the versatility with CSfC from office environment to the tactical edge. Das et al. proposed these technologies as providing capabilities for tactical users at a lower cost and detail the architecture to realize these savings.
The U.S. Navy is working on security for unclassified mission applications extended to the mobile edge. Nekoui (2012) discussed a strategy of enterprise VPNs to access U.S. Navy enterprise applications coupled with robust MDM to "remotely update, track, remotely lock, remotely wipe, and enforce policy to mobile devices"
(page 27), Although this application is for an unclassified mobile application, there are many common requirements across classified and unclassified deployments.
There are advantages to multicast for some applications. Refaei & Bush (2014) proposed a secure multicast implementation for tactical users leveraging the CSfC architecture. Applications able to leverage multicast are limited to environments where a team of operators is required to receive the same message. Tactical applications may leverage this architecture, but limited use within the mobile user (at “garrison” or home) is envisioned.
The Office of Naval Research (ONR) (2012) Mobile Security Architecture (MSA) leveraged the CSfC program from NSA for tactical users. Tactical users include military users in the field operating on military equipment and facing a unique
31 operating environment. The equipment must be ruggedized, and the normal cell phone and Wi-Fi networks are replaced by tactical military networks often with unique military radios. Commercial technology can be leveraged for these users, but this ONR
MSA must be developed with these unique requirements in mind.
2.4.4 Security Monitoring
One requirement of a composed CSfC solution incorporated monitoring on the red
(classified), black (encrypted) and grey (landing zone where only one layer of encryption resides). This monitoring is accomplished by standard commercial monitoring technology. Monitoring does not protect from system compromise but identifies when a compromise has occurred or when suspicious activity is occurring.
There are a wide range of commercial devices monitoring a wide range of elements of a
CSfC solution. These devices are improving with advances in techniques and as the market for these appliances have expanded with the recognition of the cyber risk.
King, Orlando, and Kohler (2012) discussed the need for deep packet inspection within security appliances. The authors explored both Type 1 (USG developed) and
CSfC based solutions. The CSfC standards call for commercial appliances that can support monitoring of a vast range of aspects of the network. This contrasts with a history of systems integrators "trusting" that the encryption and assuming there is no activity on the red side of the network or the assumption that activity on the black side was unimportant as it could not reach the red side. Increasingly, the importance of monitoring in the black, red, and grey sides is being recognized. King, Orlando, and
Kohler also explored the utility and techniques for this monitoring.
32 2.4.5 Mobile Operating Systems
Each mobile device includes an associated mobile operating system(s). These operating systems vary in terms of risk and performance and evolve over time to support end-user demands and the considerable market driving these development activities. Oberheide and Jahanian (2010) explored mobile security with a focus on operating systems. The comparison of mobile operating systems (OSs) illustrates at a high level the differences between the leading vendor products concerning application delivery, trust, and system isolation (Table 2-1 Mobile Operating Systems Summary
(Oberheide & Jahanian, 2010, p4)).
Table 2-1 Mobile Operating Systems Summary (Oberheide & Jahanian, 2010, p4)
Mobile Application Trust Levels System Isolation Platform Delivery Apple iPhone High low Low Google Android Medium high High RIM Blackberry Low medium Low Symbian OS Medium high Medium Windows Mobile Medium medium Medium
Nazeer et al. (2015) compared security for Linux, windows, android, etc., and they asserted that: "security development is much more robust in an open development model than in a closed secret model" (page 26). They use a hacker’s challenge as proof of the greater security with Linux. There are millions in prize money that has not been claimed for hacking a Linux box (Windows and Apple were hacked, and the prize money collected).
Rashmi and Johnson(2015) detailed the security advantages of Google Android over the Apple iOS. They describe the android architecture that leverages the Linux kernel to provide a robust security architecture. Rashmi and Johnson discussed the
33 android security model of having the author (software developer) approve applications
loading vice the iOS model where Apple corporate must clear applications into the app
store, and no other applications can be loaded.
2.4.6 Android and Security
Mobile devices use a range of operating systems. Currently, the android OS is the
only approved operating system for CSfC solutions. When composing a CSfC
solutions, it is critical that residual risks are understood, addressed where feasible, and documented under the RMF process if not.
Many mobile phone deployments do not allow phone users to add applications after provisioning, if a secure application store were provided and additional trust is required at the end user device. Dar and Parvez (2014) have proposed an android architecture that asks the user to approve any applications being installed. Often applications auto install for convenience, but clearly this is a security issue.
Hughes (2015) provided a comprehensive look at android security to include the
CSfC program from NSA. Hughes viewed android as evolving with the threats and
recognized that android as a mobile OS leader will be a target for a range of cyber
threats. Cyber adversaries wish to reach the broadest “market” and often choose the
platform with the largest number of users. Often this is included in the decision making
when selecting a mobile OS.
2.4.7 Cryptography
At the heart of secure mobile is the encryption technology that secures the
communications. Fixed sites can operate with physical security to protect classified
processing and often avoid the use of encryption technology, but with mobile this is not
34 practical and encryption is required. The USG has developed and fielded encryption technology for many years, and until recently, commercial encryption was not sufficient for USG applications.
Heron (2009) described the AES for the layperson. The current CSfC process from
NSA mandates AES with 256 bits and Elliptic Curve Certificates (ECC). The details of
AES are required for implementers, but for integrators just specifying AES (256 bits), and ECC is often sufficient. The NIAP and other testing processes ensure AES is properly implemented.
The U.S. Government (1999) recommended elliptical curves for federal government use due to the smaller key size providing the same level of security. ECCs are a specific approach to implementing AES that provides additional security over a generalized AES encryption deployment. The NSA has specified the use of ECCs to provide this additional security. AES with a high number of bits (256) is considered
“strong encryption.” All encryption can be broken if given sufficient time. Strong encryption requires a considerable time, and thus not practical [Saini and Mandal,
2015]. With advanced cryptographic capabilities, even these strong encryptions can be broken in a reasonable time. However, these advanced techniques using advanced compute technology could be many years off, and they can risk compromise of secure transmissions being made now so this “future threat” can be real against today’s communications with this compromise in the future.
Alexander (2012) first discussed legacy hardware cryptography with redundancy and cross checks built into a single hardware encryption device. The author asserted that modern systems can be built that are "stronger than their weakest link" (page 1).
35 The NSA CSfC program is held up as an example of a system that uses layering and vendor diversity coupled with robust monitoring to construct a system that when composed will be "strong" enough to support mission critical secure processing. A conventional system view would evaluate each product (or component of the larger system) for security vulnerabilities, yet fail to view these components integrated into a
larger construct such as a CSfC LZ that can be prescribed by the NSA in a capability
package for end user implementation and fielding. The days of an encryption device
that has one red connection and another black (such as a KG device) are contrasted with
the new paradigm under CSfC. This recommendation paper discussed the details of the
science to aid developers wishing to deploy this cryptography.
The field of cryptography began with USG research and continues to move steadily
to the commercial domain to support critical commercial communications such as
banking and finance. The application of “strong” commercial cryptography to the
COTS mobile capability is the foundational technology that makes these fully COTS-
based solutions for classified communications possible. This foundational piece (from
Alexander) discussed the philosophy behind CSfC composed solutions. "Trust-
Engineering" is discussed as it related to a discipline within systems and information assurance engineering.
2.4.8 Mobile Trust Module
There are some strategies for enhanced security that are not yet approved by the
NSA for CSfC applications. Mobile Trust Modules provide a strategy for security.
Hardware roots-of-trust offer security advantages over software-based trust
mechanisms.
36 Zhang, Aciiçmez, and Seifert (2007) explored mobile security as implemented
through a mobile trusted module. Techniques focused on virtualization techniques for trust within the mobile environment. Virtualization is more practical on larger compute platforms, but is still feasible on mobile devices. Additional research is required in this field and there are no current operational implementations supporting CSfC at this time
(that I am aware of).
2.5 Mobile Security Perspectives
2.5.1 Mobile Security within the U.S. Federal Government
With the expansion in mobile use within the U.S. Federal Government and the
concerns over security within a range of deployments, the Federal CIO Council and
Department of Homeland Security (DHS) (2011) established the Mobile Security
Reference Architecture (No. V1.0, 2013). The MSRA (Figure 2-13 Mobile Security
Reference Model (MSRA, 2013, p5)) identifies specific commercial software
components for a mobile deployment, but fails to address the architecture for a secure
(classified) communications and does not extend beyond the software and hardware
components required for a typical deployment. Regardless, this architecture can be
extended to address these issues.
37
Figure 2-13 Mobile Security Reference Model (MSRA, 2013, p5)
2.5.2 NSA Perspectives
As owners of the CSfC program, NSA provided insight into the history and additional details on the CSfC program beyond that which is provided on the CSfC site.
Dukes (2013) discussed the changing trust model and Internet-based transactions. The author examined both software and hardware and made the specific observation that hardware is "difficult to subvert" (page 7) and specifically recommends that implementers take advantage of this. Although there is limited discussion of the inherent limitations of hardware trust with mobile vice desktop systems, the hardware trust is explored in a general way. Dukes also made the assertion that there mechanisms are "(more) Trusted" implying there really is no fully trusted implementation. DaR concepts are briefly discussed to include encrypted hard drives.
In addition, Dukes introduced the CSfC program. Specifically, the goal to field in
38 months vice years is presented. The author discussed the improving platform trust mechanisms that are being fielded by both enterprises and COTS vendors. Clearly, the hardware trust (root-of-trust) is an important aspect of trusted secure computing and should be considered when developing an implementation.
Smalley (2013) discussed Security Enhanced Android as well as hardware roots-of- trust. This author explored advanced concepts that are often challenging to deploy operationally at this time, but will over time be more practical given the maturing of the mobile phone architectures. The virtual machine approach is discussed (there are performance issues with virtual machines on mobile platforms), as well as hardware roots-of-trust that are just now being implemented on mobile platforms. A desktop computer running the intel chip sets with the vast array of hardware roots of trust are not available on mobile phones.
Plunkett (2014), as the Director of the Information Assurance Directorate (IAD) at
NSA, gave an introduction of threats at an unclassified level in this public journal. The
Director continued with a brief introduction of various IAD programs to include CSfC.
Plunkett also made a solid case for automation within Cyber Defense tools. The author discussed the importance of maturing the cyber workforce. In this paper, the author concluded with a brief exploration of the need for resilience within the U.S.’s infrastructure. Cyber resilience has been recent theme given the wide range of recent breaches in various systems to include systems within the U.S. Government.
Watkins (2014) provided a thorough review of the NSA CSfC program and challenged industry to get on board. Moreover, Watkins argued that with the limited customer base for mobile technology vice the broader commercial market, the DoD
39 needs to get the word out on the program to get industry involved early in the NIAP
process and stay engaged on standards development.
Landau (2014) provided a rich historical perspective for the National Security
Agency. Landau focused on Communications Security (COMSEC) efforts at the
agency. The motivation behind the COTS cryptography support from NSA was
discussed, including both a reduction in cost and ease of use and deployment. The
author discussed the motivation of providing ease of use to ensure operators do not use the unsecure phones over the secure one just due to ease of use. Clearly there are valid operational concerns with communications that are only protected by the carrier's
networks (at one point cell phone traffic was not even encrypted). This author also
examined the NSA assisting the commercial firms to improve security on their
networks. The agency supports a wide range of programs and efforts, and this author
explores these programs.
Althouse (2015) discussed the current state of secure mobile and end-user need and
urgency that forms the foundation for a secure mobile architecture. Althouse
summarized the threats to the enterprise mobile devices, discussed a modern secure
architecture (CSfC based), and ended with the future of secure mobile. The author discussed the motivation for mobile capabilities and the potential risks with CSfC- based secure communications implementations. The RMF and a "shared risk" model are presented. Althouse noted that the benefits must outweigh the risks, and both are examined within this paper. As the author is employed by the NSA, the knowledge and understanding of the CSfC philosophy is well understood and fully explored in this paper.
40 Boyle (2014) discussed the history of COMSEC up to the development of the CSfC
program. The author began with a discussion of vendor involvement in the
development of USG standards. This is an important aspect of the dialog with industry.
NSA as a subject matter expert (SME) for working cryptographic technology within the
various standards bodies is discussed at length. The author pointed to future work for
the agency and industry issues to be faced incorporating environment of movement to
the mobile edge, including the Internet of Things (IOT), and asked for hardware
protections on the mobile devices and advances in end-user authentication and data
security.
2.5.3 DoD CIO Perspective
The DoD CIO recognized the importance of mobile devices; both classified and
unclassified. The DoD CIO signed out a Commercial Mobile Device Implementation
Plan (CMDIP) (2013) to address a department-wide strategy/implementation plan to
expand support for mobile devices in the DoD.
DoD Unified Capability Requirements (UCR) Research (RA) (DoD 2013)
presented a DoD Reference Architecture for unified capabilities. Unified Capabilities
refers to the integration of Voice, Video, and Data into an integrated IT environment.
This reference architecture is just one of a series of documents published under the
UCR effort within the DoD. This RA fully addressed the need for mobile devices, but
does little to address secure (classified) mobile devices. The UCR concepts can be
applied to secure mobile devices, but it must be recognized that the secure mobile
devices extend environment such as SIPRNet or Joint Worldwide Intelligence
Communications System (JWICS) networks are more limited in the richness of services
41 provided than the Non-Secure Internet Protocol Network (NIPRNet) employments.
NIPRNet access can even extend to the Internet (via gateways and firewalls) to provide a rich set of end-user capabilities for a wide range of users.
2.5.4 Military Services and Joint Perspectives
Following the introduction of CSfC, the military services are rapidly fielding a range of capabilities and differ with both requirements and strategies for fielding capabilities. The organizations implementing solutions often share lessons learned and strategies within users group and through publishing in open sources.
The Defense Science Board Task Force on Integrating Commercial Systems Into the DoD, Effectively and Efficiently drafted a report titled “Buying Commercial:
Gaining the Cost/Schedule Benefits for Defense Systems” (DoD, 2009). There were several key findings: 1) if done properly, purchasing commercial can realize lower costs, in reduced time, lower risk and demonstrated performance 2) decisions to buy commercial are increasingly complex due globalization and 3) current acquisition processes leave program managers with insufficient flexibility to work COTS into their programs.
The Army Mobility Strategy (2013) explored the needs of the Army regarding mobility and proposed specific strategies to modernize and field new capabilities for the soldier. This mobile strategy briefly discussed the needs for both traditional secure mobile as well as tactical (soldier on the battlefield) requirements. The Department of
Defense is a large organization with wide-ranging related activities that can complement the Army's Mobility Strategy. These related activities are included by reference into the strategy to create a comprehensive strategy for the service. An
42 architecture for secure mobile can leverage this approach by laying out the landscape of
related efforts and bringing them into the architecture to build out a comprehensive
framework for end-user implementation.
Bowman (2013) presented a summary of the emerging CSfC solutions. This author
discussed both travel kits and the Defense Mobility Classified Capability (DMCC)
program at a high level. Bowman presented a unique focus on the tactical end-users in the field. These capabilities currently lag behind the pilots for senior leaders and the enterprise users. Bowman pointed out that the tactical users often operate in a
"Disconnected, Intermittent, Limited Connectivity" (page 4). This is an important architectural construct to consider when fielding capabilities for these users. Bowman also reviewed the challenges with Collaboration to field these new capabilities as well as standards for interoperability. In essence, Bowman argued for the need or an architecture to aid in this collaboration.
Epstein (2014) studied the use of commercial mobile technology for the U.S.
Marine Corps (USMC). This research involved a limited discussion of classified
communications. The author asserted that commercial mobile communications
supporting classified has largely been ignored. Furthermore, Epstein recognized the
limited work in addressing policies for the support of classified processing using
commercial mobile devices.
2.5.5 Coalition Warfare
Within coalition warfare, there is a need to communicate securely with U.S.
coalition partners. Encryption technology is generally export restricted and maintained
by the U.S. for its strategic advantage. When leveraging commercial technology that is
43 fielded worldwide, such as AES, these restrictions clearly do not apply. As the North
Atlantic Treaty Organization (NATO) is a subset of coalition the issues are similar, but communication with NATO partners is more critical than other coalition partners due to mission needs.
Ionescu et al. (2012) explored an implementation of Security Communications
Interoperability Protocol (SCIP). SCIP was the preferred solution recommended by
NSA for communicating with coalition partners prior to CSfC. Ionescu et al. provided a useful historical perspective for the evolving NSA work with CSfC.
Hicks (2015) discussed theater-level cyber issues. The author identified the advantage of CSfC concerning releasability to coalition partners. Clearly commercial readily available encryption technology is releasable to coalition partners.
2.5.6 NATO Perspectives
Väisänen et al. (2015) drafted a NATO document that addressed senior leader communications and provided detailed alternatives for leveraging COTS technology from a wide range of vendors. CSfC communications on the Samsung KNOX are specifically addressed. The risk framework (Table 2-2) is an excellent construct for assessing risk. To complement the risk framework the authors proposed a range of mitigation techniques.
44 Table 2-2 Threats and Risk (Väisänen, 2015, p28)
Threat Description Likelihood Impact Tl. Disclosure of information. 4.00 5.00 T1.1 • Unintentional disclosure of information 4.20 4.60 T1.2. • Intentional disclosure of information 2.80 5.00 T2. An unauthorized use of the device 1.50 5.00 T2.1. • login to a locked device 1.20 5.00 T2.2. • Get an unlocked device. 2.00 5.00 T2.3. • Get a remote access to the device 2.20 4.80 T3. Unauthorized physical access into a device 2.25 4.00 (memory. storage. etc.) T4 . Get a physical access to the device 3.00 3.25 T4.1. • Steal the device 2.80 3.60 T4.2. • Blackmail or torture to get the device 1.00 2.80 T4.3. • Discover the lost device 2.00 3.00 T4.4. • Use the device when the user is not present 1.00 3.20 T4.5. • Bribe to get the device 1.00 3.20 T4.6. • Get the device from the user by asking it 2.60 2.80 T4.7. • Get a decommissioned device 1.20 2.80 T5. • Unauthorized remote access to a device. (See 2.20 4.80 T2.3) T5.1. • Bypass containerization 2.00 5.00 T5.2. • Escalate privile11es 2.20 5.00 T5.3. • Infect the device 3.00 4.20 T6. Social engineering attacks 3.25 4.00 T.6.1. • Attacks via phishing. voice phishing. spear 3.40 4.00 phishing. clone phishing rogue Wi-Fi access points T6.2. • Pretexting attacks. e.g., via phone. customer 3.00 3.60 service. delivery persons or Tech Support T6.3. • Baiting attacks via baits in files. fake web 3.00 3.80 sites. social networks. Etc. T7. Network spoofing attacks 3.00 4.20 T8. Lack of security patches. updates and secure 1.80 5.00 distribution T9. Jail breaking and routine of devices 2.40 2.80 T10. Reputation of the user 2.40 3.60 T1l. DoS attacks 2.60 2.00
45 2.5.7 Department of Homeland Security Perspective
The DHS is both developing a CSfC solution and is exploring enhanced security for
unclassified mobile communications for use in a telework environment. The enterprise
fixed security is usually much more secure, with the notable exception of the Office of
Personnel Management (OPM) breach, than mobile or telework. This is related to the control of the internal/enterprise environment.
DHS Telework RA (2011) explores technology and strategies for securely accessing enterprise compute infrastructure. Secure remote computing (such as telework access) can be viewed as three high-level alternatives. 1) minimal security
(clearly not recommended at this time), 2) VPN and other concepts within this paper and 3) Commercial Solutions for Classified (NSA program).
2.5.8 Department of Energy Perspective
The Department of Energy (DOE) (2013) has similar secure communications requirements to the DoD given their nuclear mission. In addition, some USG
Departments and Agencies are addressing mobility more aggressively than others.
DOE Mobility (2013) began with a discussion of the expanding need for mobile
solutions for DOE workers. It briefly explored a Pantex classified wireless initiative
using CSfC. They have considered collaborating with NSA to ensure these capabilities
can be approved. As these are emerging capabilities with a limited installed base and
established procedures, implementers are often forced to work with NSA to ensure the
fielded capabilities can be accredited. There are a number of cross-over areas (between
classified and unclassified) that are discussed from wireless infrastructure to
applications that can be accessed on the mobile devices. Access to unclassified read-
46 only sites can be accomplished via a cross domain solution (CDS). These CDS
solutions can be readily fielded by the enterprise providers on the classified web sites,
but accessed by the end-users with the mobile devices. Clearly entry of data that moves down to the unclassified sites is still a technical and accreditation challenge. DOE presented a comprehensive Mobility Strategy outline that includes 1) Business Drivers,
2) Business Model, 3) Audience Strategy, 4) Management Strategy, 5) Network
Strategy, 6) Security Strategy, 7) Platform Strategy, 8) Content and Application
Strategy, 9) Associated Policies 10) Strategy Assessment. This outline included questions for the strategy writer to consider when drafting a strategy. These high-level questions can map to an architecture for mobile solutions.
2.6 Integration Strategies
Both commercial (COTS) integration (by definition) and agile
development/integration apply to CSfC-based integration activities.
2.6.1 COTS Integration Strategies
The CSfC program requires COTS integration, but provides little discussion of how
commercial/COTS differ from standard development activities [Boehm and Abts, 1999].
An architecture for secure mobile should address these differences to aid the integrators
by being aware of these differences and planning for and addressing these unique aspects.
COTS integration involves a both the traditional systems requirements, but couples
that with an understanding of the marketplace (COTS vendors) and involves an
iterative process to fully realize the benefits of a full COTS implementation [Albert and
Brownsword, 2002].
47 With rapid commercial integration, architectural constructs are even more critical as
the systems engineer requires a construct to build specific instantiations of
communications and then continue to iterate on the design over time. There are broad
set of generalized architectural frameworks [Department of Defense Architecture
Framework (DODAF), etc.]; this paper presents a domain specific framework that is
does not constrain the wide range of mobile solutions envisioned using the CSfC
approach. Generalized frameworks are used to guide the architect of specific solutions
and provide a common approach to describing the system elements and interactions. A
more specific framework can actually aid the developer by identifying common aspects
of the various solutions (in this case secure mobile) and provide greater utility.
Research is required to develop these domain specific architectures, technical patterns
or reference architectures. In addition to jump-starting the architecture and design
process, they provide for best practices and optimally constrain the design/trade space.
Abts, Boehm, and Clark [2000] propose a COTS integration cost model and provide
an excellent review of the issues relating to COTS integration. Researchers developing
architectures that include predominantly COTS (such as the work on a COTS-based secure mobile device) can readily leverage these COTS integration issues (findings).
Boehm is recognized as an expert in cost modeling and the “COTS Assessment
Attributes,” in particular, serve as a solid foundation for a review of COTS product factors/features.
COTS has several unique characteristics that must be considered when accomplishing an integration activity. COTS benefits are extensive and are addressed
48 below. One factor that must be considered is the market research requirement; new
products are being developed rapidly to support expanding mobile market place.
COTS integration follows this general process:
1) Develop the requirements based on the user needs;
2) Review the latest products on the CCL [should be the first choice if they meet the requirements];
3) Review NIAP approved products;
4) If a product is not on the CCL or NIAP but is required for the implementation.
Performance/Capability and Supply Chain Risk Management (SCRM) issues should be evaluated and then the devices selected for the final composed solution (using factors discussed above); and
5) Assess the full architecture for interoperability and final system implementation.
Integration of COTS can involve extensive trouble shooting of integration issues with incompatible components. Reaching back to the vendor to fix “bugs” may introduce additional project delays. These factors should be planned for when working a COTS integration activity.
Boehm and Abts (1999) is a foundational piece that talks to COTS integration issues. The authors provided insight into the advantages and disadvantages of COTS integration, vice development (Table 2-3).
49 Table 2-3 COTS Advantages and Disadvantages (Boehm & Abts, 1999, p136)
Advantages Disadvantages Immediately available; earlier Licensing, intellectual property procurement payback delays Avoids expensive development Up-front license fees Avoids expensive maintenance Recurring maintenance fees Predictable, confirmable license fees Reliability often unknown or inadequate; and performance scale difficult to change Rich functionality Too-rich functionality compromises usability, performance. Broadly used, mature technologies Constraints on functionality, efficiency Frequent upgrades often anticipate No control over upgrades and maintenance organization’s needs Dedicated support organization Dependence on vendor Hardware/software independence Integration not always trivial; incompatibilities among vendors Tracks technology trends Synchronizing multiple-vendor upgrades
Abts, Boehm, and Clark (2000) proposed a COTS integration cost model and provided a review of the issues relating to COTS integration. These COTS integration issues can readily be leveraged by researchers developing architectures that include predominantly COTS (such as the work on a COTS based secure mobile device).
Boehm is recognized as an expert concerning cost modeling, and these cost factors proposed serve as a solid foundation for a review of COTS integration. In addition, the authors proposed COTS assessment attributes (Table 2-4).
50 Table 2-4 COTS Assessment Attributes (Abts, Boehm, & Clark, 2000, p6)
COTS Assessment Attributes Correctness Availability/Robustness Security Product Performance Understandability Ease of Use Version Compatibility Intercomponent Compatibility Flexibility Installation/Upgrade Ease Portability Functionality Price Maturity Vendor Support Training Vendor Concessions
COTS integration involves a both the traditional systems requirements, but couples that with an understanding of the marketplace (COTS vendors) and involves an iterative process to fully realize the benefits of a full COTS implementation (Albert&
Brownsword, 2002).
2.6.2 Agile Development
Agile was originally applied to software engineering, but with the integration of commercial technology agile has particular methods can readily be applied. Agile includes defined sprints (short development cycles) with user input and feedback.
Commercial integration can be rapidly accomplished and readily demonstrated to an end user or sponsor.
In addition, COTS integration that involves a continuous update and enhancement process (life-cycle perspective) has many parallels to agile development. Agile strategies can be applied to secure mobile communications integration and sustainment activities. Agile development brings many benefits with some disadvantages that can
51 be addressed through a process balanced between agile and traditional methods.
Managed change (a principle of agile) can be accomplished readily through COTS
integration through limited end-user software customization, end-user input in the
product selection process, and finally a recognition that early and often feedback from
an end user during the pilot phase and allow for valuable end-user input will result in
user satisfaction.
The Agile Manifesto [Beck et al., 2001] can directly contribute to the development of systems realized using this architecture by readily adapting some of the principles
(others are directly applicable). The following are an adaptation of the first three points from the manifesto to illustrate the applicability to this domain:
1. Deliver a working secure mobile solution early and then evolve the design by
integrating additional capabilities (additional COTS hardware and software).
2. Do not resist requirements change, as the change out of a COTS software or
hardware component requires minimal effort (as contrasted with development) for the
integrator and provides benefits to the end-user.
3. Early capabilities can be demonstrated; such as a secure call and then minor
updates can be rapidly demonstrated to the customer (don’t wait for a “big bang
integration” at the end).
Systems engineers work to manage systems complexity through rigorous
requirements and lifecycle management process. At first look it appears agile will not
be embraced by systems engineers. A recognition of the environment, though (constant
technology change and the ability to rapidly change out commercial hardware and
software), should bring systems engineers to the realization that agile methods can be
52 applied to these integration activities. Specifically, the systems engineering “vee” model can be applied, with Agile added, by encouraging the systems engineers to “fall back down” the “vee” and revisit past engineering decisions to embrace the Agile
Manifesto’s constructs to realize an optimal design leveraging rapidly changing commercial technology and cost effective integration of commercial technology. These efforts are not about development with the associate downstream cost impacts (of change); this is a commercial component integration activity.
Agile development brings many benefits with some disadvantages that can be addressed through a process balanced between agile and traditional methods. Eng
(2014) proposes a range of techniques (Table 2-5 Agile Factors (Eng, 2014, p30)) to provide balance between the two methodologies.
Table 2-5 Agile Factors (Eng, 2014, p30) Factor Agility Discriminators Plan-Driven Discriminators Size Well-matched to small products and Methods evolved to handle large teams. Reliance on tacit knowledge products and teams. Hard to tailor limits scalability down to small projects. Criticality Untested on safety-critical products. Methods evolved to handle highly Potential difficulties with simple critical products. Hard to tailor down design and lack of documentation. to low criticality products. Dynamism Simple design and continuous Detailed plans and Big Design Up refactoring are excellent for highly Front excellent for highly stable dynamic environments, but a source environment, but a source of of potentially expensive rework for expensive rework for highly dynamic highly stable environments. environments. Personnel Requires continuous presence of a Needs a critical mass of scarce critical mass of scarce Cockburn Cockburn Level 2 and 3 experts Level 2 or 3 experts. Risky to use non- during project definition, but can agile Level 1 B people. work with fewer later in the project – unless the environment is highly dynamic. Can usually accommodate some Level 1B people. Culture Thrives in a culture where people feel Thrives in a culture where people comfortable and empowered by feel comfortable and empowered by having many degrees of freedom. having their roles defined by clear (Thriving on chaos) policies and procedures. (Thriving on order)
53 Flora et al. (2014) discussed agile development and the application to mobile
application development. Quantitative analysis is presented to support the assertion.
2.7 Systems Engineering of Architectures
Systems engineering includes a wide range of sub disciplines including
architectures. There are systems, capabilities, enterprise, reference, frameworks, and
other architectures, which include a wide range of types.
Architectural frameworks are critical tools for systems engineers operating across
the full spectrum of applications. With rapid commercial integration architectural
constructs are even more critical as the systems engineer requires a construct to build
specific instantiations of communications and then continue to iterate on the design
over time. There are broad set of generalized architectural frameworks (DoDAF, etc.).
In this paper, I present a domain-specific framework that does not constrain the wide
range of mobile solutions envisioned using the CSfC approach.
Cloutier et al. (2010) proposed that a reference architecture should address related family of systems and is “below” the architecture frameworks. Frameworks can support a reference architecture for related efforts or systems and each system follows the reference architecture, but is specific to the implementation.
Davis, Mazzuchi , and Sarkani (2013) proposed an architecture for technology
transitions. The case study approach and the proposed architecture demonstrated a
useful construct for a wide range of domains. Some of these strategies were leveraged
for this research (and are noted below).
Quarles (2012) explored an architecture for the leveraging of Intelligence,
Surveillance, and Reconnaissance (ISR) to support dynamic emergency management.
54 Within the DoD, considerable investments have been made in ISR processes and
technologies that can be readily leverage by emergency managers with considerably
less resources. The strategy for leveraging involves first developing a reference
architecture. The ISR community being a component of the DoD uses the DoDAF
process. Quarles also explored leveraging these DoDAF views from the ISR programs
(well-funded and mature efforts) to apply to the emergency management field.
The Veteran's Administration developed an integrated Enterprise Portal Reference
Architecture that provides an excellent example of a reference architecture (Figure 2-14
DoD/VA IEPRA (DoD, 2015, p1)). This reference architecture supports mobile and
fixed users for the Veterans Administration and is a good example of the enterprise
focus that is extended to the mobile edge (top layer). Regardless of the end-user location the rich enterprise services are offered up the end user. There are a wide range of enterprise environments that are not fully explored in the research: the VA provides a good exemplar.
55
Figure 2-14 DoD/VA IEPRA (DoD, 2015, p1) Gamez, Fuentes, and Troya (2015) proposed a reference architecture for IoT
(Figure 2-15 Conceptual Reference Architecture: IoT (Gamez, Fuentes, & Troya,
2015, p110)). Some key security issues identified with IoT apply to secure mobile include tamper resistance, data privacy, data communications and storage security
(direct relationship to secure mobile), network communications security (again, relates to secure mobile), and privacy with IoT technology including sensors and embedded computing. With IoT there is increase concern with privacy relating to the consumer markets concerns with privacy.
56
Figure 2-15 Conceptual Reference Architecture: IoT (Gamez, Fuentes, & Troya, 2015, p110) Singh, Mudholkar, and Balani (2015) provided a recent summary of architecture frameworks (Table 2-6). As DoDAF is required for DoD and the majority of secure mobile solutions at this time are being developed by DoD the research has focused on extending this framework (more to follow). In addition, the DODAF is particularly mature and comprehensive.
Table 2-6 Types of contemporary Enterprise Architecture (EA) frameworks (Singh, Mudholkar, & Balani, 2015, p3) “Types of contemporary EA frameworks are listed below:
1) Consortia-developed frameworks ARCON – A Reference Architecture for Collaborative Networks – not focused on a single enterprise but rather on networks of enterprises [11][12] Generalized Enterprise Reference Architecture and Methodology (GERAM) RM-ODP – the Reference Model of Open Distributed Processing (ITU-T Rec. X.901-X.904 | ISO/IEC 10746) defines an enterprise architecture framework for structuring the specifications of open distributed systems. IDEAS Group – a four-nation effort to develop a common ontology for architecture interoperability ISO 19439 Framework for enterprise modeling TOGAF – The Open Group Architecture Framework – a widely used framework including an architectural Development Method and standards for describing various types of architecture. 57
2) Defense industry frameworks AGATE – the France DGA Architecture Framework DoDAF – the US Department of Defense Architecture Framework MODAF – the UK Ministry of Defence Architecture Framework NAF – the NATO Architecture Framework
3) Government frameworks European Space Agency Architectural Framework (ESAAF) - a framework for European space-based Systems of Systems [13]. Government Enterprise Architecture (GEA) – a common framework legislated for use by departments of the Queensland Government FDIC Enterprise Architecture Framework Federal Enterprise Architecture Framework (FEAF) – a framework produced in 1999 by the US Federal CIO Council for use within the US Government (not to be confused with the 2002 Federal Enterprise Architecture (FEA) guidance on categorizing and grouping IT investments, issued by the US Federal Office of Management and Budget) NIST Enterprise Architecture Model
4) Open-source frameworks Enterprise architecture frameworks that are released as open source: LEAD Frameworks. LEAD is an abbreviation for Layered Enterprise Architecture Development and is the only community-driven open source EA framework built upon international standards that is in use today. LEAD consists of frameworks, methods, and approaches that are all integrated with to each other and with supporting maps, matrices, and models. MEGAF is an infrastructure for realizing architecture frameworks that conform to the definition of architecture framework provided in ISO/IEC/IEEE 42010. Praxeme, an open enterprise methodology, contains an enterprise architecture framework called the Enterprise System Topology (EST) TRAK – a general systems-oriented framework based on MODAF 1.2 and released under GPL/GFDL. SABSA[10] is an open framework and methodology for Enterprise Security Architecture and Service Management, that is risk based and focuses on integrating security into business and IT management.
5) Proprietary frameworks ASSIMPLER Framework – an architecture framework, based on the work of Mandar Vanarse at Wipro in 2002. Integrated Architecture Framework (IAF) – from Cap gemini company in 1993 Dragon1 - An open Visual Enterprise Architecture Method recently recognized by The Open Group as Architecture Framework DYA framework developed Sogeti since 2004. Dynamic Enterprise Enterprise architecture concept based on Web 2.0 technology Extended Enterprise Architecture Framework - from Institute For Enterprise Architecture Developments in 2003 EACOE Framework– an Enterprise Architecture framework, as an elaboration of the work of John Zachman[1]. OBASHI – the OBASHI Business & IT methodology and framework Information FrameWork (IFW) – conceived by Roger Evemden in 1996 Purdue Enterprise Reference Architecture developed by Theodore J. Williams at the Purdue University early 1990s. SAP Enterprise Architecture Framework Zachman Framework – an architecture framework, based on the work of John Zachman at IBM in the 1980s. Service-oriented modeling framework (SOMF), based on the work of Michael Bell.”
58
Sefid-Dashti and Habibi (2014) proposed a reference architecture for mobile service
oriented architectures (Figure 2-16) provides an excellent example of a reference
architecture. The layers of Governance, Information, QoS and Integration allow for a discussion of the primary facets of the architecture that are included in this reference architecture.
Figure 2-16 Mobile SOA Reference Architecture (Sefid-Dashti & Habibi, 2014, p414) Meissen and Voisard (2010) proposed a reference architecture for early warning
RADAR. The authors noted the importance of capturing the processing or functions of the various subsystems, but avoided the specific allocation of these elements to specific hardware elements. They discussed the migration to Service Oriented Architecture
(SOA) and other technologies where the functions and applications can be provided as
59 a service to the end user (or other compute elements). In addition, Meissen and Voisard
summarized the current thinking concerning architectures and specifically reference architectures.
2.8 Mobile and Legal Issues (and Privacy)
There are two broad areas of legal issues: encryption over borders and intercepting of signals as well as lawful intercepts (legal wire taps). Some literature addresses these issues.
Roos, Hartman, and Dutnall (2003) introduced some early concepts of encryption legal issues with moving across national borders as well legal interception of signals.
The mobile protocols 2G and 3G are rapidly evolving, but Roos, Hartman, and Dutnall took an early look at roaming worldwide.
Bellovin et al. (2006) discussed lawful intercepts in relation to the then emerging
VOIP technologies and wide spread deployments. The authors reviewed the early challenges for supporting law enforcements needs to conduct lawful intercepts (when lawful procedures are followed - court order, etc.) Bellovin et al. also highlighted the challenge of maintaining a lawful intercept capability given the rapid development of a vast range of VOIP solutions.
In a more recent article, Bellovin et al. (2014) discussed lawful intercepts at length and the required technology. They discussed the desire by law enforcement to have new technology that is “wiretap friendly.” CSfC solutions that are being deployed for
USG users to conduct classified work are not being developed to be “wiretap friendly” for obvious reasons.
60 In a related article, Bezzera et al. (2015) discussed the growing mobile marketplace and considered the security of consumer data to support privacy and how data are used.
The authors emphasized the balance of the utility of farming metadata with protection of customer privacy. The security of the communications channel is assumed to be secure from the vendor providing transport and the focus is therefore NOT on the company use of the data that it has acquired in the normal course of doing business for this research activity.
2.9 CSfC Vendor Applications/Solutions
Vendors building routers, firewalls, and mobile phones that are on the CCL and are integrated into a composed solution are not explored in this research as the scope is too broad and the integrators are to look at the current CCL and do the research to compose a solution that meets end-user requirements. These vendors are selling to the open commercial market and the focus is on leveraging their vast research and development
(R&D) and consumer market for these secure mobile solutions.
Vendors building integrated solutions for USG use are emerging and are more limited in scope and are explored and summarized within this section. Often, the USG does not yield the full benefits of CSfC if the solutions are employed vice an integration of the leading IT products from CISCO and the like.
Vendors providing specific elements (APPS) that fit within a complete CSfC solution (Mocano, 2012) present the capability within the larger systems architecture.
Borrowing from the published NSA specifications their respective capabilities are highlighted as a solution within this context.
61 There are a number of vendors now advertising specific CSfC solutions (General
Dynamics, 2013) and (Boeing, 2014). The vision is for CSfC to be fully an integration of commercial products that are mass produced for the standard consumer market and readily available to be integrated into a solution for secure/classified communications.
DoD vendors General Dynamics (GD) and Boeing are advertising partial solutions (the phone) that have completed some engineering, but still requires additional components and integration for a complete operational capability. Boeing developed unique hardware for their CSfC solution. Standard android phones, such as those sold to the consumer market, are sold at the rate of hundreds of millions of units per year that produces clear economies of scale and reduced costs for U.S. secure communications end users. The USG contractors developing solutions can only expect sales in the hundreds or maybe thousands so the costs are anticipated to be higher and product upgrades are anticipated to lag the consumer market. Some vendors (Juniper, 2014) discussed the advantages of CSfC solutions, but did not mention specific COTS products or solutions. It's envisioned that COTS products are under development that support CSfC solutions, but are not to market.
Information Assurance Specialists have developed a Small Tactical Executive
WAN (STEW) (2015) that is a contractor developed integrated CSfC solution. This solution adheres to the CSfC standards, but is not envisioned to support standard commercial applications and is, therefore, closer to a GOTS solution. If the vendors can cost effectively integrated commercial devices in a small form factor, these are close to COTS solutions that may realize the benefits.
62 McAfee and Harris Corp. (2013) vendor literature described a cyber hardened
Google android device with McAfee and Harris hardware to present a composed solution for end users. This vendor literature demonstrated that vendors cannot advertise a single vendor product to "sell" CSfC solutions, but must instead propose a composed solution for end-users. The vendor literature specifically calls out the leveraging of the CSfC approach from NSA for secure communications. This is just one of hundreds of potential CSfC composed solutions. A generalized architecture was not presented, but a specific vendor "box" solution was provided.
Jueneman (2013) recommended a "belt and suspenders" approach to trusted computing. This author proposed a layered security architecture and then pointed to the
NSA CSfC program as adopting the same strategy (“belt and suspenders”). Jueneman asserted that hardware-based encryption provides higher levels of security and this particular vendor sells products that do that support this approach.
A Motorola (2012) white paper made a case for security on mobile comms and directs the reader to more information on a Motorola web page. The vendor strategies for mobile vary from conceptual to early product marketing to mature fielded products.
The integrator must review this vendor literature and engage with vendors to fully understand the maturity of the products and features of the products to compose a solution. Vendor research is an important integration challenge.
Viasat (2013) proposed COTS-based secure mobile for use overseas with both commercial cellular and Viasat's COTS Satellite Communications (SATCOM) capabilities. This marketing literature demonstrates the wide range of potential solutions as well as more evidence of the viability and vendor support for CSfC.
63 Raytheon (2013) proposed a Virtual Desktop Infrastructure (VDI) with an
integrated CSfC solution (from the VPN capability package). The approach can
provide savings from the VDI deployment and layers in an NSA proven process for
classified processing. The mobile edge was not addressed, but the white paper
demonstrated a solid approach for fixed communications.
Vendor literature from CACI (2015) proposed a NFC card with a display to provide
hardware based certificates to a Samsung phone. The hardware-based certificates are more secure, but "soft certs" are acceptable by the DoD for secure communications as long as they are in a "secure store."
Lindteigen and Officer (2014) discussed a composed CSfC solution without presenting the technical details. These authors focused at a high level the motivation and the solution being composed for the mobile user.
2.10 Conclusions
With secure mobile leveraging a rapidly changing field and composed of a wide range of technologies, it is critical that systems integrators understand the diverse technologies and stay current with the technology. An architecture can aid in organization of the technologies that are being applied and provide a framework for tracking, assessing, selecting, and integrating technologies into a composed solution with the highest user capabilities, at the lowest cost, and containing the highest cyber resilience. These three factors must be balanced for each component of the solution architecture. Solution architectures must include compatible technologies to realize the final aspects of an optimized operational capability.
64 Chapter 3 - Research Framework
3.1 Research Gap
There is a clear gap in architectures for secure mobile driven by new technology that
is just now enabling the development of fully CSfC communications. Systems engineers
and architects have been refining strategies for the development of architectures that both
aide the development of systems and ease integration of systems that are increasingly
complex and are rapidly moving to “systems of systems” constructs to rapidly field a
wide range of communications systems with increasing capability. The gaps fall into the following general areas: 1) Architectures, 2) Secure Mobile, 3) Secure Mobile Using
CSfC and 4) Mobile Technology.
Gaps by Research Focus Area:
Commercial Mobile Communications
The consumer market is vast and ever changing. Market research must be on-going
to leverage the latest technology for secure mobile. Product knowledge is well known
by the various independent vendors, but a consolidated understanding of the range of
products must be built through a methodical technology following process. A reference
architecture supports a methodical technology following thorough product
classification and standardized lexicon. Products such as intrusion detection systems
can have a vast range of product features, and these must be understood by integrators
of solutions. Vendor terminology can be confused by marketing, and product features
might be partially implemented. The integration and testing process will identify this
issues, and coordination with vendors can often resolve these issues.
Systems Engineering
65 The systems engineering discipline as applied to COTS integration is relatively well
understood. With the integration of COTS, there is no development of hardware and
software so design issues identified late in the development cycle are not an issue. The
focus remains on hardware and software requirements up front, as well as selection and
integration to field a capability rapidly.
Architectures
The utility of architectures within the development process has not been fully
explored and for DoD systems is required, but often the utility is not well understood.
There are a range of frameworks that can be selected and possibly extended for a
particular application. There are a range of architecture levels from Enterprise, to
Reference, to Solutions that can cause confusion with architects and practitioners.
Encryption
Encryption developed by the USG for USG classified information dates back many
years, but the application of commercial encryption for USG use is a recent strategy
and is therefore not well studied or mature. Banking and other disciplines requiring
high levels of security could leverage the USG strategies for secure communications, but to date there has been limited work in this area.
Summary of the Research Gap and Focus of this Research
The NSA has provided a capability package for secure mobile, but has not extended this to a reference architecture that will support the application of the CP to a specific end-user application. The guidance could be considered the minimal information required to implement a solution that would receive an authority-to-operate (ATO).
The ATO is the final step in an implementation and involves a thorough review of all
66 the guidance from NSA as well as the adherence to the requirements of the RMF
process (and requirements).
3.2 Research Objectives and Questions
In this research study, I focused on an architecture for a new approach to using
commercial technology to secure communications for a wide range of applications.
The architecture evolved over time to accommodate additional aspects required to
implement a full solution. The following research objectives and questions with
research objectives support the associated research questions.
Question 1: What is the architectural framework for COTS based secure mobile
solutions? Supporting Objectives: A) Development of a research construct and
framework for on-going literature review of relevant topics in support of the
architecture. B) Drawing on the research, develop an architecture to support answering
the research question. C) Refine and optimize the architecture to ensure maximum
utility for future integrators of secure mobile solutions as well as future research in this
transformative technology.
Question 2: How well does the architecture meet requirements given real-world implementations of secure mobile? Supporting Objectives: A) Identify appropriate case studies’ base capabilities fielded or under development (limited to about a dozen).
B) Develop a questionnaire that will draw out aspects of the architecture to and help refine the architecture. C) Using case study feedback, refine the architecture and verify the completeness and validity of the architecture.
Question 3: Are there lessons learned and future areas of research in this area?
Supporting objectives: A) Lessons learned and future areas of research are gathered
67 throughout the research activity. B) Lessons learned are discussed in relation to the developed architecture C) Areas of future research are organized and presented in alignment with the literature review areas identified early in the research.
These questions address the research topic presented in Chapter 1 and support this transformative new approach to resilient and secure communications. A systems- engineering approach is applied to expand on work being done in this field and more fully address factors and issues relating to fielding of a composed solution.
The methodology for answering these research questions is addressed in Chapter 4 and findings presented in Chapter 5.
68 Chapter 4 - Research Methodology
4.1 Research Methodology Overview
The NSA has developed a foundational architectural construct, and this paper builds on this architecture to propose a richer architecture for the wide range of solutions being developed by the community.
Systems engineers leveraging the NSA CSfC approach coupled with this architectural framework can readily implement solutions to meet the wide range of mobile solutions to support the ever-expanding mobile needs of our increasingly mobile workforce. Early adopters of this approach will be Government users
[Väisänen, 2015] desiring to secure classified communications (as the Government requires these safeguards, but users requiring highly secured communications such as banking and finance and law-enforcement are evaluating these strategies from NSA and are envisioned to be candidate users of both the NSA strategy and the architecture introduced in this paper. The final Government approval process for the solution is clearly not required for commercial users, but all other constructs and strategies apply to a broader set of users wishing to have these highly assured secure communications.
A systems-engineering approach was applied to the development of the secure mobile architecture. At a high level, the research methodology follows the systems engineering “vee model” (Figure 4-1). When applied to the specific domain of an architecture for secure mobile based on COTS using case study research, it takes the form of Figure 4-2.
69
Figure 4-1 Systems Engineering “Vee Model” (Stevens, 1998)
Figure 4-2 Systems Engineering “Vee Model” (Stevens, 1998) Applied to Architecture Development In general, the “vee model” begins with a high-level description of the user requirements and then as the implementer (or integrator) moves down the left side of
70 the “vee,” there is an additional, more detailed, definition of the solution. As the
implementer approach the bottom, they have gotten very detailed in the description of
the very finest details of the solution (could even be detailed hardware/software
specifications). For COTS integration, this is in the vendor space (and not shown in the
diagram). As the implementer moves back up the right side of the “vee,” they develop the lowest level pieces and then move to integration of the lower level components. At each level, the implementer can look back to the left side of the “vee” to verify the solutions are conformant with the specifications that have been created coming down the “vee” at each level. The final step is a “validation” that the system meets the end-
users needs. Variations of the “vee model” exist, but this general construct provides for
a view of both the construct for the contribution of the mobile architecture to the
development process as well as a generalization of the development of an architecture
using a formalized systems engineering construct.
71 1 4 Continuous research due to Initial Objective evolving technology (and Policy) Monitor CSfC Program @ NSA 2 Initial Lit Review 5 & Present Early Vendor Technology Confirm Gap Findings 3 Research Gap Review Initial Refine Objectives Requirements 6 13 Research Publish Objectives Early 18 Focus Lit Review Results Initial Architecture Development Expert 7 Full Lit. (Expansion of Step 8) Judgment Review Systems Engineering Approach 9 Pathfinder Programs Requirements 8 Initial 14 Case Study Architecture Questions 10 11 Ideal Architecture 16 15 Architecture Alternatives Refined Case Studies Architecture Returned 12 Refined and Validated Trades for 17 Conclusions Optimal Arch Future Research
Figure 4-3 Architecture Development Methodology The complete research methodology involves case study validation and publishing
of results (Figure 4-3 Architecture Development Methodology). Each numbered step
is detailed as follows:
Step 1. Initial Objectives - Research began with expert judgment used to develop
the research objectives and to scope the effort. Recent technology trends have driven
the research gap and associated needs:
Commercial Mobile Technology - Technology has enabled vast improvements in
mobile voice, video, and information services.
Commercial Transport – with the development of LTE and ubiquitous Wi-Fi, connectivity is improving rapidly.
Technology Costs – with competition and scaling, technology costs are reducing.
Technology in the hands of an increasing number of users is vastly more affordable.
72 Technology Investments – with the vast technology investments within industry,
USG technology/capabilities are lagging commercial tech within this domain.
Cyber Threat – expanding cyber (and intelligence) threats to the work force have increased the requirements for improved security across all information technology environments.
Mobile Security Technology – recognizing the threat, the USG and commercial
users are increasingly demanding cyber resilient technology. At the present time, a
robust secure mobile implementation would involve layered encryption of VOIP calls
with the addition of robust cyber tools (intrusion detection systems, firewalls, etc.).
With these very secure implementations of mobile, there is a nominal impact in
performance and should only be implemented when these security mechanisms are
required by operation necessity (banking, defense, the thwart corporate espionage).
Unfortunately, the use of this technology by U.S. adversaries (terrorists) can impact its
operations. These issues are being explored in the media and are not addressed in this
research.
U.S. Government Policy – the USG has recently allowed a “robust” completely
commercial implementation of mobile technology (CSfC) to be used to transport
classified information. In addition, to encourage industry involvement in this program,
the NSA has provided many of the details on an open site for integrators and vendors to
develop against. These recent trends have created the anticipated research gap that was
explored with the initial literature review.
Step 2. Initial Literature Review - An initial literature review was conducted to
explore the research gap. The initial literature review was accomplished only to
73 solidify the understanding the current research in this field and was reviewed to unsure the gap did exist.
Step 3. Research Gap - The research gap was confirmed and the research objectives were solidified. The research gap is an architecture to support secure mobile communications. The security is at the high end of the spectrum and the mobile included a broad range of technologies. Current work, within the various fields identified above (in the literature review section), was used to fully bound and scope the research gap to be explored.
Step 4. Continuous Research (CSfC and Vendor Tech) - Within these technology fields there are rapid changes, so continuous research during the entire research process was required to ensure the latest technology was understood. The
CSfC program at NSA was continually evolving. In particular, the capability packages were regularly being updated, and new products were being added to the CSfC products lists.
Step 5. Present Early Findings - Following the literature review and development of an initial research strategy and preliminary findings, these were presented to at the
NDIA 17th Annual Systems Engineering Conference in Springfield, VA on the 30
October ’14. The topic was of interest to the attendees and provided validation of the importance of this research and the broad interest within the systems engineering community. A simplified architectural construct was presented to illustrate the range of end users equipment coupled with a range of transport options (or combinations) reaches back to the enterprise environments.
74 Step 6. Research Objectives - The research objectives were developed, and included the development of an architecture framework that has broad applicability to secure mobile communications implementations, validation of the architecture using case studies, and identification of potential future research activities within this field.
The architecture objectives were:
• Applicability to USG communications developed under the CSfC construct • Applicability to commercial applications requiring the highest levels of security • Provide benefit to implementers/integrators and future researchers. Dimensions of the benefit includes reduced development time at a lower cost with the highest performance (“Better, Faster, Cheaper” - NASA).
Step 7. Full Literature Review - The full literature review involves extensive research (summarized above). Open source literature from NSA as well as research papers from a range of areas supports the development of an architecture framework.
Step 8. Initial Architecture - The initial architecture (below) was developed and each element was explained to support the entire system construct.
Step 9. Requirements - The development of the architecture involved the application of the systems engineering paradigm. The requirements for the architecture were developed to include quality attributes:
• Utility: High utility (specific to secure mobile) – aides developers. Note: standard generalized frameworks such as DODAF, Federal Enterprise Architecture (FEA) provide more limited utility for the developer, but can support a broader use.
• Adaptability: Low adaptability; given this is a more specific architecture (sub domain) – this is a trade-off to achieve utility (above)
75 • Affordability: The architecture identifies minimal commercial components to realize the solution (this is required by NSA). Extensions are allowed by the solution owners.
• Auditability: In support of the security requirements, the architecture facilitates robust monitoring and audit features using affordable commercial components.
• Autonomy: An example is the LZ can operate autonomously (with limited human interaction). Some maturation of technology is required to support the mobile components (over the air updates, provisioning etc.).
• Availability/Reliability: Availability/reliability is a function of the component reliability of the components coupled with redundancy (2 LZs). Redundancy is an aspect that is reserved for the solutions architecture/integration team. Improved reliability can be achieved through the acquisition of redundant solutions (two secure phones would be an example).
• Composability: With a COTS integration design, the architecture is inherently composable.
• Correctness: This is a function of a verification against the requirements to include conformance with Government policy (CSfC polity from NSA).
• Degradability: For improved degradability, the architecture should be extended with additional capabilities (see availability above).
• Interoperability: The architecture full addresses interoperability to include specific discussion of interoperability with legacy systems and “backend” (red interoperability).
• Scalability: The architecture is scalable by replicating landing zones and procuring additional mobile devices. Some loading analysis and tuning is required.
76 Step 10. Ideal Architecture - An ideal (not constrained) architectural construct
was developed.
Step 11. Architecture Alternatives - The full range of alternatives were explored
with the associated strengths and weaknesses. Many of the architecture alternatives
were addressing achieving optimal utility (providing specificity for this secure mobile
domain) which trades off adaptability (for other uses). DODAF and other frameworks
can be applied to a vast range of solutions, domains, and applications. This architecture
is limited to solutions for secure mobile. This fundamental trade must be understood:
Highest Level – Framework - DODAF/FEA, etc., High Flexibility, low utility
(for Secure Mobile solutions integrators)
“Mid-Level” – This Proposed architecture, Lower Flexibility, High Utility for Secure Mobile solutions (the trade space is between the level above and level below)
Most Detailed - Solutions architectures are left to the developers of specific solutions.
Step 12. Trades for Optimal Architecture - Engineering trades were conducted to develop the final, practical architecture. One critical dimension of the trade is what level of architecture provides the optimal utility for the end-user of the architecture: the solution architects/integrators. The solution architects were able to contribute to the trades required.
Step 13. Publish Early Results - Early results are being published in a journal article. The architecture presented captures the full range of critical elements within the
77 architecture framework. The final architecture framework will add additional details
for a more comprehensive framework.
Step 14. Case Study Questions - The initial architecture was provided with the
case study questions to help the respondents understand the entire construct and
respond appropriately. The questions were aligned with the construct to assist the
respondents in framing appropriate responses in alignment with this early construct.
Questions begin with an overview, follow along the elements of the initial architecture and end with an open-ended question (Appendix B).
Step 15. Case Studies Returned - Case studies from various secure mobile implementations were received, and these were used to validate the existing architecture.
Step 16. Refined Architecture - To fully capture the complexity of the range of
implementations, a more detailed and methodical architecture will be required.
Step 17. Develop Conclusions and Identify Future Research - Finally,
conclusions will be derived from the research and future research topics will be
identified and described for future researchers in this field.
Step 18. Expert Judgment - The case study respondents are SMEs in their
respective fields. Expert judgment was used to verify early requirements and
architectural aspects as well as to validate the end-user requirements are being satisfied.
4.1.1 Strengths and Weaknesses
The strength of the approach is the ability to integrate evolving requirements from
the Government (NSA) as well as various implementations that are currently at various
stages of development. With a rapidly changing commercial marketplace, vendor
78 technology monitoring (or following) is critical throughout the entire development
(shown as a cycle in the upper right). The weakness is that even more refinement that
is continuous could be integrated into the methodology, but a general flow is required
to realize an effective architecture and focus the systems engineer on a realization that
revisiting aspects of the architecture is critical. Future implementations that leverage
this architecture would clearly provide additional insight and allow for refinement of
this architecture (potential future research). A reference architecture must be
maintained and kept current to have utility. The integrators and community must
support this long-term maintenance activity.
4.1.2 Extensibility
This methodology could be applied to a range of domains. For many domains, the
Government direction would be limited (as they may not receive direction from NSA), but other policy bodies could be addressed and the general process/methodology readily applied. A generalized architecture framework has broader applicability (such as DODAF), but does little to assist the developer other than providing a common
“language” to describe a solution architecture. A domain specific architecture (i.e., secure mobile) provides value to future secure mobile implementers by providing a
“technical pattern” without overly constraining the design space. With increased reliance on commercial technology and expanding complexity of systems integration activities, these technical patterns are growing increasingly valuable and are clearly
fertile grounds for future researchers.
79 4.2 Case Study Data Collection Questionnaire
The case study questionnaire was developed leveraging the work done by another researcher working on an architecture framework (Davis et al., 2012). The questionnaire addressed aspects of the anticipated architecture to aide future projects in developing secure mobile solutions. A spreadsheet for the questionnaire was chosen to facilitate quantitative analysis of responses (although limited). The first tab of the
Excel workbook provides an overview for the responders. The questions were grouped in the following way:
Sheet 1: Instructions – this provided an overview of the research and provides high-level information.
Sheet 2: Questions – Secure Mobile Survey
Section A. Tell me about you
Section B. Capability Overview
Section C. Specific Questions (Architecture) – this section follows the
structure of the architecture envisioned
Section D. Development Perspective
Section F. Missing Questions – catch all.
4.3 Case Study Characteristics
As discussed, the CSfC approach is new, and only about a dozen solutions have been implemented to date. The NSA CSfC website asks solution integrators to register with them so the agency is aware of the full range of implementations (this information is not shared with the public). The community can share implementation strategies and lessons learned through a range of technical interchange meetings (TIMs) and technical forums.
80 These solutions are varied (Figure 4-4 Focus areas for Case Studies) and were each potential case studies for this research. A summary of the key characteristics of these solutions are:
• Development Phase – are they early in development or fully completed and
operational?
• User Base – are they supporting a specialized user community or a more
general/enterprise solution?
• Alignment with the NSA Capability Package – which capability package was
adopted – example - Wireless LAN or Mobile Access (MACP)? Also, how
closely was the capability package followed?
• Alignment with Components List – how many of the selected devices are on
the NSA components list?
Each solution can follow closely the guidance (capability packages from NSA) provided or deviate from this guidance and accept the risk (solution owners “share” the risk with the NSA). Solutions with deviations (from the capability packages) often are upgraded (over time) to more closely align with the capability packages (and thus reduce risk). The registration involved a summary of the components selected to support the capability package, but does not address the larger integration issues that are at the center of the case study research accomplished within this study. Key The largest enterprise solution (DMCC) and two senior leader applications were selected as the representative samples for case study research and validation. Some organizations were reluctant to share integration details due the nature of the mission and the supported user base. The senior leader (national level) communications community are early adopters of the CSfC
81 approach as senior leader require secure communications and this community is staffed and resourced to develop and field the latest technology for these critical users. In addition, the enterprise solution (with potentially thousands of users) was a logical selection. Finally, a beta lab implementation was selected for the case study research.
This implementation was particularly constructive in looking at cutting edge strategies for implementing secure mobile solutions. The case study questionnaires (and interviews) were completed by both technical program/project managers as well as systems engineers on the same activity to gain multiple perspectives and they provided valuable insight and lessons learned that were incorporated into the reference architecture developed under this effort. In addition, these engineers were able to provide critical validation of the eventual architecture in terms of its completeness and utility for future integrators of this critical capability. The legacy systems are end of life (cellular carriers are no longer supporting the devices) and these capabilities need to be brought on line quickly.
Tactical applications with unique requirements were not selected and represent unique characteristics. The deployments are predominantly within DoD and DHS. Other departments and agencies are planning to use the DoD or DHS initial deployments for secure mobile communications. The DHS effort is currently lagging behind DoD.
Finally, clearly, there could be foreign or domestic R&D development activities that are on-going and were not considered as case study candidates.
82
Figure 4-4 Focus areas for Case Studies Organizations supporting this case study research were provided a questionnaire and responses were collected. The enterprise solution is a “commodity” phone that the
Defense Information Services Agency (DISA) has developed and is fielding to the largest number of users.
“DoD Mobility Classified Capability (DMCC) is an enterprise service providing classified mobile access to the Secret Internet Protocol Router Network (SIPRNet). DMCC devices are portals to the classified networks; there is no data at rest. DMCC leverages commercial technology and products to the greatest extent possible while allowing access to SIPRNet e-mail and secure voice communications via a secure Voice over Internet Protocol (VoIP) capability. Bringing these capabilities to a mobile device allows mission partners greater flexibility in secure communications.” (http://www.disa.mil/enterprise-services/mobility/dmcc/secret, assessed Dec 30, 2015)
83 The other organizations are smaller and wish to extend their communications to the mobile edge. These early adopters are critical organizations with robust communications teams. In the future, there is envisioned to be a wider set of users, and more of the routine users will have this capability. No permission was granted to include any specific details of the organizations or their users. The DISA deployment has been shared with the media, thus this specific solution has been referenced. The case study responses were aligned with the architecture framework to verify the architecture and at times the architecture was adjusted to accommodate details from the case study responses.
4.4 CSfC Compliance Crosswalk
One critical aspect of each implementation is the compliance with the CSfC CCL. A compliance tool was developed in Excel (refer to Appendix C). This is a proof-of- concept for one facet of the architecture framework for compliance with the NSA published component list.
First, the vendor selected components for the composed solution off the CCL (if there is a component available). The composed solution was documented and presented to the
Authorizing Official (AO) under the RMF process. Each component can be identical a product on the CCL or just similar. The compliance crosswalk tool developed during this research allows for a visual of the entire range of products and a match to the CCL. The systems engineer utilizing the tool determined compliance (green) or if there was no product on the CCL. it was clear from the matrix. If the product was “close” to the product on the CCL, a color (yellow) denoted this. The compliance crosswalk is a formalization of the adherence to a USG (NSA) directed product vetting process
(discussed above).
84 Chapter 5 - Research Findings
5.1 Initial Architecture Framework
Taking a macro view of the implementation of secure mobile solutions, one way to view the range of options is to view the options as a combination lock and to “dial” in the desired configuration. Start with the end-user equipment. Is the desired device a phone, tablet, computer, and/or other mobile device? Then move to the access networks. Does the device need to operate over cellular, Wi-Fi, and/or the wide range of emerging wireless access mechanisms? Finally, the communications are “landed” in a landing zone that is connected to an enterprise communications environment, such as
JWICS, etc.
Combination Lock” Analogy
Secure mobile communications using the CSfC approach can involve a wide range of end-user-devices, access networks, and enterprise services. A combination lock provides an interesting analogy (Figure 5-1 "Combination Lock" Analogy). The wheels can be rotated to “compose” vast range of solutions to support the end users. A mobile phone connected via cellular to the JWICS environment (or enterprise) was demonstrated. Interoperability was provided via connections on the “back end” or via enterprise interconnections. This flexibility to compose a wide range of solutions using commercial technology was the primary benefit of this architecture.
85
Figure 5-1 "Combination Lock" Analogy This combination lock analogy and introductory material was presented at the 17th
Annual Systems Engineering Conference, Springfield, VA, 28-30 Oct ’14 (Gump,
Sarkani, & Mazzuchi, 2014). This architecture was refined over time to incorporate additional details. The architectural framework (Figure 5-2) begins with the NSA elements and presents extensions to realize a more complete architecture.
Figure 5-2 Architecture Framework
86 Enterprise Benefits
There are a number of enterprise benefits that can be socialized with the stakeholders
to build sponsor support. They can be summarized as “faster, better, and cheaper.”
Faster in that the capability can be fielded more quickly. Better as the communications
voice quality can often be improved over legacy communications. Cheaper as the large
commercial market is leveraged (economies of scale).
Time to Field Latest Technology. USG mobile technology has been lagging behind
commercial mobile technology development partially due to the commercial market
being considerably larger than the USG market. The USG can leverage the vast
commercial investment in mobile technology. An integration activity that involves
predominantly commercial technology can be accomplished within months and fielded
rapidly to ensure end-users have access to the latest technology at commercial prices for
an added benefit. Although, at this time, the primary users of this technology are USG
users requiring advanced security this architecture supports a broader range of users.
Banking, law enforcement, etc. are typical users of advanced mobile security.
Cost Advantages. Economy of scales for commercial mobile devices ensures that
the millions of cell phone users continue to drive cost-effective mobile devices for the standard commercial consumer. The market for secure mobile is considerably smaller than the mobile consumer market, but nonetheless can leverage the massive consumer market. These advances include the full range of technologies required by a CSfC solution, from end user devices, to mobile device management software, to phone security for standard consumers.
87 Loss of Devices. As mentioned previously, in the past, secure mobile phones and
devices leveraged government-developed encryption devices that were classified as CCI.
The loss of CCI would involve a risk to the U.S. and would trigger an investigation and
considerable effort and operational impact would be experienced. With the use of CSfC,
these devices are now standard commercial technology. When reported as lost (within a
reasonable time), the devices are “removed” from the network. The impact of a loss is
much diminished and presents a great savings to the range of implementing agencies.
Pure COTS: Although in this paper I focused on COTS and contrasted this with
GOTS, there are hybrids of the two. One example is a product developed by a vendor for
the limited USG market such that it is a commercial product but does not realize all the
benefits of COTS. The Boeing Black phone is an example of a “hybrid” phone. These
EUDs are typically more expensive than standard COTS phones that are used by the
standard commercial users. These devices still present enterprise benefits, but all factors
must be weighed to ensure the optimal selection of components is selected, integrated and
fielded.
Enterprise Requirements/Policy
Introduction. With the introduction of transformative technology, there often are
policy implications that will be resolved over time but are just now being addressed.
Requirements. End user requirements can be summarized at a high level as the
following Figure 5-3 illustrates. Start with the user needs move to an understanding of
the enterprise that is being extended to the mobile edge, select a device, and then
determine the locations where this device must operate.
88 1. User(s) &High Required Level Requirements Applications • Senior Leader, Comms Officers, etc • Voice, Video, Email, C2, BA, etc
4. Location(s) 2. Enterprise Extended • Enterprise unclass, Secret, • Aircraft, Vehicle, on foot, etc Composed TS/SCI, etc • Government and/or • Services available Commercial Solutions • US and/or OCONUS
3. Device(s) & Transport • Phone, Tablets, Laptops, etc • w/ WIFI, Cellular, etc
Figure 5-3 High Level Requirements Policy for Use. With technology advancements, policy is often slow to react. A wide range of policy changes are required to fully support these new technologies. These mobiles devices allow for classified operations anywhere in the world. The approved locations, operations, mission, and, in general, the operating parameters must be considered and policy needs to be developed to guide the proper use of these devices. A simplified Policy Framework (Figure 5-4) summarizes the issues. The risk dimension
(Figure 5-5) augments the policy framework.
89
Figure 5-4 Policy Framework
Figure 5-5 Risk Profile
90 Priority Treatment on Public Access Networks. DHS maintains a Wireless
Priority Service (WPS) program to ensure National Security and Emergency
Preparedness personnel have priority treatment during a crisis or event (Figure 5-6).
During these events, the commercial nets become congested, and a signaling mechanism
is required to provide this capability. The WPS program issues a “calling card” that
provides for calling codes that are entered by the end-user on their standard cellular
phone. The current secure phones use a standard voice call (standard switched
telephony) to initiate the call, and then a “go secure button” that is invoked after the
standard voice call is initiated. As the secure communications migrate to a CSfC-based approach, new challenges are emerging to effectively implement these mechanisms. The
CSfC-based calls are VOIP calls that travel as encrypted data paths through the cellular network. Signaling the tower using voice channel dialing prefixes can’t be supported as the voice channel is removed on the device for all calls except 911 calls (that are retained for legal reasons). Exploration for solutions to this issue is currently under development.
91
Figure 5-6 Priority Service Issue User Experience
These secure mobile phones must be protected with end-user authentication in mind, and this often conflicts with ease of use desires. Nevertheless, these requirements must be considered in any deployment. Single button dialing, directory services, and a wide range of end-user features can, and should be, integrated into the secure mobile device.
Security requirements balanced with a rich feature set ensures fielding of a secure and capable end user device. The MACP specifies some aspects of the EUD, with other aspects left to the implementer.
Transport
Introduction: The transport can be any “black” (encrypted traffic) communications mechanism that is required to support the user (Figure 5-7). Often the required operating locations drives (Figure 5-8) the transport requirements. In addition, devices may utilize multiple communications mechanisms in a single device. Access to the transport is
92 managed by the transport owner, but open architectures should be planned where feasible. For example, a USG Wi-Fi implementation should support devices from a wide user base to egress the Wi-Fi transport using pre-coordinated security access mechanisms.
Larger Capacity/More Capable Users Temporary User at Personal Permanent Facility (Corporate and Government) - WIFI
Travel Temporary Facility Kit (Hotel, etc)
What Operating Direction for Locations? Solution Developer
Figure 5-7 Operating Locations Required
93 What Transport is Required? Government Network Direction for Public Network Solution Developer Government Network Public Network Hot Spot Public Cell Networks End-User- Or Government Cell Networks (Tactical) Landing Device (s) Vehicle Zones Cell Kit (EUDs) To get to Enterprise Government Network Public Network LMR
Government Network Public Network SATCOM
Don’t forget the Threat – Signal Intercept, Cyber, etc (Risk)
Figure 5-8 A Sampling of Transport Alternatives If there is a time where no transport exists, these disconnected operations can be robust, such as off-line e-mail creation and filing or can be limited to the device having no utility while disconnected. Factors such as form factor for the EUD, DaR, etc., factor into the design decisions and planning.
Cellular: Clearly, the commercial cellular providers’ offerings must be leveraged with minimal (if any) impact to the existing cellular infrastructure. Due to the nature of the CSfC approach, the voice is carried over the data channel vice the voice channel. The voice is limited to 911 calls, and after making a call, the device is inoperable for secure calls until the device is re-provisioned.
Standard Wireless (Wi-Fi): One key transport mechanism is via enterprise- provided Wi-Fi. This does not include public Wi-Fi that has limited security and can’t be standardized at this time. Wi-Fi access is often protected via a range of mechanisms. For
94 multiple implementations to share deployed Wi-Fi access mechanisms, it’s critical that organizations collaborate and standardize the access mechanisms. This paper will explore techniques for shared Wi-Fi.
Others: Other transport options include temporary network connections, such as in a hotel. They may include a combination of transport options, operating in series. The full range of Internet Protocol (IP) transport mechanisms can support these secure communications with the proper management of risk and prior planning with a
comprehensive systems engineering approach to exploring all options to support the end-
user.
Enterprise Services
Enterprise services include the full range of voice, video, and data services. These
range from secure voice calls, to streaming video, Video Tele Conference (VTC)
sessions, and secure e-mail. Services and features of the various enterprises [DoD, DHS,
Department of State (DOS), etc.] vary, and these secure mobile devices can be viewed as
an extension of the enterprise services. The mobile devices mirror the enterprise services
and provide a seamless transition from fixed enterprise services to the mobile edge as
much as is practical given the devices screen size, bandwidth limitations, and other
obvious factors.
Interoperability
Introduction: The NSA MACP focuses on the strategy to accomplish a single
instantiation of a CSfC-based communications system. Interoperability is predominantly
accomplished with the “back-end” or “red side” of the architecture. Several design issues
need to be considered when planning for the interoperability of the wide range of
95 implementations of CSfC solutions, as well as interoperability with legacy
communications.
Dialing Plans: Standard “10 digit” dialing is well known and understood with
international dialing codes used to reach other countries’ telephony. With these secure
mobile solutions, the “dial tone” is provided by the individual implementations and not
the commercial telephone network.
Existing secure phones operate at a range of classification ranges [to include Multi-
Level Security (MLS)] and are developed and fielded by a range of departments and
agencies. Secure phones are able to call other secure phones using call prefixes (similar
to country codes). Clearly, security protocols are followed to ensure phones at one
classification level call to the same level on the other phone. MLS phones can support
multiple levels and can call across security level. As new phone systems are deployed
simplified dialing plans are being developed to ensure ease-of-use for the operators, but will be accomplished following approved security guidelines. When planning a secure mobile implementation early dialing plan coordination can ease the operator’s burden with these complex communications systems.
Dialing Across Classification Levels: Mobile devices are extensions of enterprise information technology implementations that provide services (voice, video, and data) to end-users. These enterprise services can support a single classification level or multiple levels. The single levels include: unclassified, secret, top secret, etc. These standard
DoD classification levels can be mapped to other federal departments and agencies classification levels to allow for interoperability across domains. Accreditors have allowed for calling across classification levels using a range of techniques that have been
96 explored in this paper and are anticipated to evolve over time as the technology supports
additional implementations.
Integration with Legacy Communications
Legacy communications include a broad range of communications systems. They
range from VOIP systems that are completely “red” (classified) and NSA GOTS
encryption-based phone systems. These communications systems have existing
interoperability mechanisms that can be maintained to ensure interoperability. Systems
that are at a fixed classification level, obviously, cannot interoperate (above).
Risk Management Framework
There are a number of cyber risks to be aware of with these secure communications
implementations. The DoD mandated RMF provides a standardized process across the
department. The RMF leverages the NIST processes that are standardized across the
whole of government (all federal departments and agencies). The RMF process identifies
the full range of residual risks within an IT implementation and then tracks that risk over time to “manage” the risk. No longer do you work the ATO, put it on the shelf and wait
‘till it expires and then work another ATO – the information security team works
throughout the program life-cycle to continuously access risk and work to diminish the
residual risks. With a commercial technology based secure mobile implementation there
are new commercial products being developed regularly that should be leveraged to
upgrades and sustainment of the capability. Even with a comprehensive security strategy,
not all risk can be eliminated (or needs to); some can be accepted, and the operator of the
system can be confident that the highest risks are eliminated and security of the system is
ensured. Details regarding other nations’ (or threats) efforts to intercept secure
97 communications are highly classified and not addressed within this architecture (and this
research).
Although RMF is a new process (2013) foundational elements are common so the
framework is being readily adopted for this community. Some additional features (to
managing residual risk discussed above) of RMF and the alignment to the secure mobile communications application are:
“Baked-in” Security - With RMF the security features are to be baked-in during development (and not added in after the fact). Note that RMF applies to all systems; those processing both classified and unclassified information. With secure (classified) communications systems NSA mandates security appliances within the capability packages therefore the CSfC approach complements the requirements within the RMF as security appliances are required for processing classified that meets or exceeds the
RMF requirements. As updates to the capability packages are made security is a critical concern for the agency.
Reciprocity - The CSfC program supports the development of multiple implementations using a common NSA strategy. The RMF process also recognizes reciprocity as a strategy for increased efficiencies. Reciprocity involves one community that authorizes and accredits a solution, being leveraged by another solution using the same configuration and approach. Even the publication of the CSfC guidance (capability packages and associated risk assessments) involves a reciprocity strategy. The NSA develops these products and integrators adopt these and are able to more efficiently accredit the system (leveraging security artifacts from NSA).
98 Although the DOD is allowing for transition to RMF it’s critical that secure mobile
migrate to RMF to achieve the enhanced security mechanisms within the RMF to secure
the critical communications of the early adopters (senior leaders).
Supply Chain Risk Management
SCRM is broadly concerned with the risk to supply disruption (natural disaster
affects a factory, etc.) and that of the integrity of the products within the supply chain.
For secure mobile applications, the integrity of the products is of the greatest concern.
When composing secure mobile solutions, all risks must be evaluated SCRM risks
should be included in the risk calculus.
The USG, in particular, is concerned about the integrity of the Information and
Communications Technology (ICT) it currently purchases. NIST Special Publication
800-161(2013) summarized the risk as: “These ICT supply chain risks may include insertion of counterfeits, unauthorized production, tampering, theft, insertion of malicious software and hardware, as well as poor manufacturing and development
practices in the ICT supply chain” (page 4).
SCRM involves an understanding of the wide range of risks and strategies to
mitigate these risks. “An acquiring organization can also compare its risk posture, risk
tolerance and risk appetite carefully against detailed objectives for security, reliability,
safety, quality and, ultimately, trustworthiness” (Windelberg, 2015, p7). With a project entirely composed of commercial products, every component in the system should be evaluated in terms of supply chain risk. Additionally, this should be balanced against the cost of risk mitigation strategies to include performance impacts of components that have a lower risk profile, but do not perform as well in the composed solution. All
99 solutions will include some residual risk: integrators should aggressively manage this
risk and recognize, and ultimately accept, all residual risks to field affordable and
capable secure mobile solutions leveraging the latest commercial technology.
Phone-to-Phone
This capability is not currently supported by the NSA-developed capability
packages, but does mirror the previous generation of secure phones that supported
direct phone-to-phone calls. It’s important to discuss this potential future capability, but it should be noted that this approach would limit the enterprise services that can be offered. This does present some advantages. Specifically, the infrastructure of a
“landing zone” is not required to implement these capabilities. One could envision an austere telephone network in a foreign country with operators wanting to communicate securely with each-other while deployed.
5.2 Final Architecture Framework
With the importance of the DoD Architecture Framework (DoDAF) within secure communications implementations, DoDAF was selected to be adapted for use within implementation of secure mobile communications. The case study findings and initial architecture were leveraged to develop a DoDAF based architecture for secure mobile communications (Figure 5-9 DoDAF Based Secure Mobile Architecture).
100
Figure 5-9 DoDAF Based Secure Mobile Architecture The “Reference Architecture for Mobile Security (RAMS)” is built on the
successful CSfC program from NSA. The framework extends the CSfC guidelines for
a reference architecture that is fully implementable. At a high level, the standard
DoDAF viewpoints are evident with additional details that provides for the secure
mobile user perspective.
Cyber Secure – All systems need to be cyber secure based on the criticality of the information system and the data being protected during transmission. A secure mobile
solution supporting classified communications needs a robust cyber security solution in
accordance with (IAW) NSA direction within CSfC and RMF. Cyber security can be
accomplished through an integration of a number of standards and additional systems
engineering to extend and strengthen the fielded capability.
Capability Provider – The organization responsible for providing the solution to
the mobile user (the eventual user of the mobile solution). The capability provider
101 should keep the end-user needs and requirements in mind, but often the end-user needs
to be consulted.
Mobile User – This is the end-user that will want a simple to use, highly capable solution that can be operated in any environment. Many of these perspectives can be readily anticipated, but some require early and on-going interaction with the mobile user. The mobile user is concerned about the capability viewpoint and operational viewpoints.
Project Manager – This stakeholder is responsible for the project completion and has the Project Viewpoint as a focus area within the architecture.
Systems Engineer (and Architect) – The systems engineer is concerned with the entire process and architecture with a focus on a systems viewpoint and for the architect
(all views).
All COTS – This is a reminder that these solutions must draw on COTS hardware and software, and this is a critical constraint for the systems engineering of a composed solution.
Enterprise Owner (External to the solution) – The mobile solution is the edge of the solution boundary and involves the extension of an enterprise solution (and service such as voice, video and data) to the mobile edge. Often enterprise owners can identify services using a service viewpoint description.
Secure Mobile (CSfC Standards) – These standards are critical enablers for the capability and are highlighted within the construct.
For each of the views, only specific views from those required under DoDAF are selected as recommended views to capture the requirements for secure mobile. These
102 views are drafted as templates and provided in Appendix D. The architecture details are provided in the templates for users to update for the range of applications and use with their respective architecture and systems engineering activities.
5.3 Lessons Learned from Case Studies
The architecture evolved over time to incorporate additional details required to fully address all the aspects of a secure mobile solution. The case studies added additional details with the final architecture being a derivative of the DoDAF architecture.
Summary of the select issues observed and associated lessons learned and resolution into the final architecture:
A. Issue: Technical Issues Integrating Capability Into Existing Operating
Environment
Findings: Fielding was delayed with integration issues and bringing the capability on line is not yet achieved for one capability. Other capabilities are on line and operational.
Lesson Learned: Early planning for the deployment and potential issues with integration into the operating environment needs to be planned for.
B. Issue: Development Timelines may be Longer than Expected
Findings: The best observed timeline is 7 months, yet often can take a year to integrate and field capability.
Lessons Learned: When working, the project schedule should plan for a year of development, integration, and test at the minimum unless an aggressive timeline is well planned, and appropriate resources are dedicated.
103 C. Issue: Phased Capability may be Required
Findings: End-users may want everything (voice, video, and data), but a phased rollout of capabilities over time may be more practical or achievable.
Lessons Learned: The Project Viewpoint supports a view with a phased rollout by
capability (was added to the standard template).
D. Issue: Some Users Resistant to Change
Findings: Technology change brings organizational impact and resistance to
change within some organizations.
Lessons Learned: Socialize the coming changes and work with the users’
organization to ensure proper training is accomplished and view impacts to personnel
as a potential issue with fielding. Effort can be viewed as a small “Business Process
Re-Engineering” activity.
E. Issue: Life Cycle Funding not Always Secured
Findings: Although a life cycle cost estimate was developed, there was a failure to
secure sustainment funding. An additional deployment did not accomplish a life cycle
cost estimates, but has secured funding for development, deployment and sustainment
(existing operating funds can cover this new capability). No view of cost savings over
legacy capability [Secure Mobile Environment Portable Electronic Device (SME PEDs)
or similar] was accomplished, but the cost is anticipated to be higher and ROI comes
from capability for the end user.
Lessons Learned: Project viewpoint can incorporate funding plans and the
Architect/Systems Engineer can work with the financial management folks to plan out
the project funding.
104 F. Issue: Policy for Use Issues
Findings: Firm policy is under consideration, but devices are expected to be
treated as unclassified while powered off and classified Secret (or higher) when powered and connected (logged into) the network. Policy is lagging the technology.
Use within a secure facility is still not understood. Use of a Top Secret (TS)/Special
Compartmented Information (SCI) device outside a SCI Facility (SCIF) is still not understood. Use of Wi-Fi in a SCIF for classified is also not well understood.
Lessons Learned: Draft policy documents can be created early in the development and coordinated with proper officials to establish policy for proper use of these devices.
In addition, policy issues can be elevated to higher headquarters resolution.
G. Issue: MDM Solutions Immature and Not Integrated
Findings: A robust MDM solution is not integrated into any of the case study implementations. MDM solutions can aid the end-user by automated some of the management functions on the device, but these capabilities were not integrated.
Lessons Learned: Research on MDM solutions should be accomplished and
integrated prior to CSfC approval (there are not solutions available on the list yet). One
case study is tracking a new MDM solution, currently in development, that will use the
Samsung CellWe (MDM). The combination of the CellWe (MDM) and the Knox
server (security feature enabler) may be the first accepted, fully commercial CSfC
phone provisioning system that provides the initial securing of the devices as well as
managing them from the MDM console.
105 H. Issue: Usability Features Not Fully Explored
Findings: One button dialing or other ease-of-use features important to end-users, but limited work was accomplished to integrate these capabilities.
Lessons Learned: An end-user perspective and associated templates should be included and encouraged in the architecture.
I. Issue: DaR Solutions Immature
Findings: Solutions immature so DaR is not being incorporated. The applications like Outlook Web Application (OWA) are not as capable as the apps (applications that provide a richer e-mail experience).
Lessons Learned: Again, this relates to the end-user experience. DaR solutions involve additional techniques such as encryption of the devices memory and are often not explored, but the end-user experience could be enhanced through a DaR solution.
J. Issue: Transport (cellular and Wi-Fi) Options Still Limited
Findings: Most solutions include Wi-Fi and cellular, but only one at a time (not simple automated transition). Often commercial cellular is accomplished over MIFI hotspot vice direct use of cellular. Security advantages drive solutions overseas that include a MIFI requirement. End-users carry a cell phone and a MIFI hotspot to complete a secure phone call. Again, end-user satisfaction will be impacted be requiring users carry multiple devices. A standard USG Wi-Fi environment is not fully understood. There are some pilot efforts for USG Wi-Fi, but a complete “standardized” robust solution for multiple USG facilities is not understood or currently fully planned out.
106 Lessons Learned: Each configuration with multiple devices should be captured in
a simple way in the architecture and each configuration shared with the end-user and other stakeholders to get approval for the device configurations. In addition, unclassified calls cannot be made with these devices, and this needs to be made clear to the end-users.
K. Issue: User Authentication not Optimal
Findings: Password, passphrases, and personal identification numbers (PINs), no biometrics have been employed that could improve on usability.
Lessons Learned: Again, include a Concept of Operations (CONOPs) or related view that clearly demonstrates end-user issues.
L. Issue: Higher Classification Levels Achieved Over Time
Findings: The end-user often wants higher (TS/SCI), but the implementers are starting with secret and working to TS/SCI over time. Often the classification level of the enterprise being extended drives the classification level of the end user device.
Lessons Learned: Incorporate a phased build-out of capability over time; with the capability being the classification level (Secret > TS, etc.).
M. Issue: Accreditation Involves the Mobile Capability and Impacts Other
Systems Accreditation
Findings: The ATO for the capability can be secured more easily than the accreditation with other systems that this secure mobile phone connects to.
Lessons Learned: Early planning for RMF and coordination with owners of other systems can facilitate a smooth RMF process that does not delay fielding.
107 N. Issue: Risk Assessments on Solutions Lacking
Findings: Implementers often just used NSA risk assessments and did little additional work on risk. There are a wide range of risks to the secure mobile phone solutions that should be explored and risk mitigation strategies adopted for deployed solutions.
Lessons Learned: Architecture products should include a robust risk management process to ensure risks (from threats such as communications collection) should be incorporated.
O. Issue: Supply Chain Risk Management not Fully Addressed
Findings: Solutions integrators bought hardware from “reliable vendors.” No additional research was done on vendors or mitigation strategies that have been incorporated.
Lessons Learned: There is no strategy to completely eliminate the supply chain risk, but some techniques can be incorporated and readily adopted. This factor should be integrated into the architecture.
P. Issue: Effect Program Management Lacking
Findings: There are Program Management requirements on the vendor implementing the solution as well as the USG that is acquiring the solution.
Lessons Learned: Project Management strategies can be clearly worked within the
Project Viewpoint and worked from the integrator up to USG to drive effective project management.
108 Q. Issue: Phone-to-Phone
Findings: No interest or requirement from the case study solutions, but this could be tracked over time.
Lessons Learned: Mentioned in the architecture, but no strategy is being developed to accomplish this at this time. Note: the legacy phones were fully able to call each other and then go secure.
R. Issue: Development Challenges and Associated Delays
Findings: Evolving technologies (to include products) and increased customer expectations (poor requirements management).
Lessons Learned: Development spirals planned out with technology roadmaps and customer expectations management is required for effective project management.
Project Viewpoint (PV)in can help integrate capabilities early in the project lifecycle.
S. Issue: Priority Service over Cellular
Findings: Some organizations are proactive in working with the community to solve the issue while other organizations do not appear to be aware of the issue.
Lessons Learned: Architecture, capabilities, and limitations should be shared with the end-users. These lessons learned were incorporated into the architecture and the architecture evolved over time.
T. Issue: Vendor Support for CSfC Products required
Findings: Some vendors are reluctant to support certain products that require a more complete CSfC solution. Secure VTC, secure data access, and DaR areas in particular.
109 Lessons Learned: Often on-going dialogue with vendors is required to encourage them to invest in the development (or modification of existing) products.
U. Issue: Voice Quality Varies Greatly
Findings: Voice quality over a CSfC solution is dependent on a variety of factors, but the most critical is the backhaul network (reliable cell, commercial SATCOM with high bandwidth, etc.).
Lessons Learned: Plan on implementing with most capability backhaul for the highest voice quality in the composed solution.
V. Issue: Integration of the Mobile Device with the Client Apps
Findings: The integration of the mobile devices with the client applications (VPN,
VoIP, etc.) can be full of pitfalls.
Lessons Learned: It is best to put the vendors together to see if they can work something out between themselves for best integration.
W. Issue: Authorizing Officials Not Experienced with CSfC
Findings: There are often delays with accreditation of the solution due to AOs inexperience with CSfC.
Lessons Learned: Work early in the development process with the AOs and their staff to ensure they understand what is involved with CSfC solutions. If required, get with NSA to help explain CSfC to the AO.
5.4 Architecture Framework Implementation
An initial architectural framework was developed that expands on the work from
NSA to support the broader systems engineering requirements to realize a field-able solution. The architecture is not able to be used by the current, early adopters, but must
110 wait for the architecture to be developed and leveraged by future implementers (Figure
5-10).
Figure 5-10 Early Adopters Support Architecture Development The architecture framework supports the full range of secure mobile using CSfC with limited support for tactical applications as these solutions have a wide range of variability to address the tactical environment. Integration with the dozens of tactical communications systems is the predominant challenge. Both the USG and industry solutions requiring highly secure communications can implement these solutions.
The initial architecture was extended using DoDAF to provide a more thorough and detailed architecture framework to address the full range of issues. Individual solutions will require additional details to “flesh out” the architecture for their respective solutions, thus the proposed framework was required to stop at the “seam” where the individual solutions begin.
The case studies only explored implementation strategies at a high level. The range of implementers of these solutions is wide and they vary with regards to development
111 maturity. A Capability Maturity Model (CMM) provides an excellent framework for measuring maturity within an organization. However, the architecture framework was
not required to address this and stopped at a recommendation of the application of agile
recognizing the benefits within a COTS integration activity that involves a complex
integration of hardware and software often involving products just fielded and not
mature in the product life cycle.
5.5 Architecture Flexibility
Flexibility to compose a wide range of solutions using commercial technology is the primary benefit of this architecture, while maintaining compliance with guidance from NSA. The security should be viewed as layers with the foundational capability being those capabilities required to operate the initial system. Additional security appliances can be readily integrated into the architecture as required meeting end-user security requirements. A long-term commitment to enhancing and maintaining a secure solution architecture based on the latest affordable technology to ensure the communications are secure is required. Leveraging the commercial market for these solutions ensures the rapid availability of the latest commercial technology for rapid integration, test, and fielding. The architecture provides a framework for addressing the wide range of issues with a secure mobile solution without being overly prescriptive.
RA Utility
One risk factor in development of an RA is to drift too far in either direction (as depicted in Figure 5-11). An RA that is too high level and does nothing to aid the integrator or improve interoperability needs to be brought back in line. In a similar way moving to too far “down” would overly constrain the solution space and the integrator
112 would not be free to innovate and produce the optimal solution. With the rapid changes in commercial technology this is even more critical and this balance must be carefully weighed when developing the RA. The entity responsible for the RA from “cradle to grave” can ensure this optimal level and working with the full range of stakeholders can achieve this outcome. Acquirers must seek out and incorporate these RAs and embrace the RA construct for them to be effective.
Figure 5-11: Simplified Architecture Hierarchy Recognition of Utility – when first developing a capability a design element or component will be recognized as having multiple instantiations within an enterprise.
For an example, the secure mobile landing zone is envisioned to be developed by multiple stakeholders within the enterprise and the solution is complex enough that a pattern would have utility for integrators. Another reason for developing a RA is to improve interoperability of system components. For example, if a RA were developed for Government WIFI then a wide range of users could roam across a range of
Government WIFI deployments. Note that a single solution integrator would not be
113 motivated to develop a RA, but would instead develop a solution and implement without thinking through or investing in a more generalized RA for the broader community’s use.
Development (and Maintenance) of the RA – an organization charged with management of an enterprise would recognize the utility (above) and develop and maintain the RA for community application.
End-user of the RA – the stakeholder responsible for a single implementation, leveraging the RA, would apply the RA tailored for the particular application.
Recommendations for the changes to the RA would be provided to the developer of the
RA. For contracted development activities the use of the RA can be levied on the developer. A test of the utility of the RA would be adoption of the pattern without a hard contractual requirement.
Expanded Use of COTS Drives Greater Need for RAs
Development of large IT systems with complex integration of multiple COTS components drives the utility of RAs for integrators. The greater the complexity of the integration the greater the need for a RA to aide integrators.
Proliferation of COTS Vender Unique “Special Features” Beyond Industry
Standards
COTS vendors will often develop systems in conformance with industry standards, but will add custom vendor features that go beyond the standard to secure product differentiation and secure greater sales. RAs can address these issues with non- standard features and make recommendations for implementation to optimize design choices and ensure interoperability across common enterprise solution elements.
114 Government Standards
Just two decades ago, much of the Government acquisition process was driven by
Government standards. Currently, limited use of Government standards is recommended with commercial standards and best industry practices leading the way.
A RA can be viewed as a Government standard and care must be taken to limit the application of these RAs and within the development of the RA to limit the constraining of the solution space for future developers/integrators. The RA should minimally constrain and include only guidance that provides utility to the integrator or aides in systems interoperability as required in the mission space. To implement a mobile solution fully, the minimum standards are required and do NOT constrain the solution space, but instead ensure a secure mobile solution is implemented, minimally constrain ultimately for a secure solution. Putting this all together; the Government standards guide the capability provider in product selection and allow for efficient capability integration (Figure 5-12).
115 Government/ Product Capability Enterprise Vendor Provider Guidance Solution Requirements
Reference Architectures SelectTechnicalTechnical RAs (if Available) 1. NIAP Validated Pattern 2. NIAP and on the CCL Pattern 3. Other Protection Selection Profiles COTS SelectTechnicalTechnical Products Pattern Pattern Capability Products CollectionCollection Packages Integrate STIGs (IA) (and Configure)
GOTS RMF Operate (maintain)
Figure 5-12: RAs in Support of Secure Mobile
5.6 Conclusions to Research Objectives and Questions
Returning to Section 3.2 (above), I have evaluated the research against both the questions and the supporting objectives.
Question 1: What is the architectural framework for COTS based secure mobile solutions? Supporting Objectives: A) Development of a research construct and framework for on-going literature review of relevant topics in support of the architecture. B) Drawing on the research, develop an architecture to support answering the research question. C) Refine and optimize the architecture to ensure maximum utility for future integrators of secure mobile solutions as well as future research in this transformative technology.
Q1, Obj A - Figure 2-1 illustrates the research construct and Chapter 2 documents the review of the literature. With the pace of change in this field, the literature review
116 continued throughout the research effort to ensure the latest papers on this topic were
incorporated. I used automated search tools from Google Scholar and other sites to
trigger an automated e-mail if papers were published on CSfC due to the critical nature
of these papers to this research. On-going interaction with the NSA provided additional
insights.
Q1, Obj B/C – The research findings and appendices fully describe the architecture
that addresses both prior work in the field as well as the case studies accomplished
during this research.
Question 2: How well does the architecture meet requirements given real-world implementations of secure mobile? Supporting Objectives: A) Identify appropriate case studies based on capabilities fielded or under development (limited to about a dozen). B) Develop a questionnaire that will draw out aspects of the architecture to and help refine the architecture. C) Using case study feedback, refine the architecture and verify the completeness and validity of the architecture.
Q2, Obj A/B – Organizations were selected and the questionnaires were released.
(Appendix B)
Q3, Obj C – The responses were summarized as lessons learned (Section 5.3) and
integrated into the final architecture (5.2 and Appendix D).
Question 3: Are there lessons learned and future areas of research in this area?
Supporting objectives: A) Lessons learned and future areas of research are gathered
throughout the research activity. B) Lessons learned are discussed in relation to the
developed architecture C) Areas of future research are organized and presented in
alignment with the literature review areas identified early in the research.
117 Q3, Obj A – Lessons learned and future areas of research were gathered and summarized in Section 6.1 (research lessons learned) and 6.3 (areas for additional research.
Q3, Obj B – Lessons learned were discussed in relation to the architecture (section
6.1).
Q3, Obj C – Areas of future research were organized around the literature review construct and described in Section 6.3.
118 Chapter 6 - Conclusions
With the rapid changes in technology, a generalized framework is required to aid the systems engineers implementing these new commercial secure communications. The requirements vary, but an extension to the NSA-provided capability package (this proposed architecture) will assist implementers in applying the USG direction and readily fielding capabilities. This research explored architectural framework alternatives for secure mobile implementations, building on the foundational work from the NSA and applying a methodical systems engineering approach to effectively field mission capability systems for the most critical applications in the U.S. Government.
Commercial technology applied to classified (secure) communications for the whole of Government is an emerging capability. An RA for these solutions provides utility for solution providers and enterprise owners. Beyond the secure mobile applications there are a broad range of applications for RAs for enterprise owners and these should be explored by enterprise owners and acquisition professionals. The development and life- cycle management of RAs provides benefit beyond the investment required.
6.1 Overview of Research, Results, and Benefits
Secure mobile communications using commercial technology is a transformational technology. The NSA has developed a foundational architectural construct, and in this dissertation, I built on this architecture to propose a richer architecture for the wide range of solutions being developed by the community. Systems engineers leveraging the NSA
CSfC approach coupled with this architectural framework can readily implement solutions to meet the wide range of mobile solutions to support the ever-expanding mobile needs of our increasingly mobile workforce.
119 Early adopters of this approach will be USG users desiring to secure classified communications (as the USG requires these safeguards), but users requiring highly secured communications such as banking and finance and law-enforcement are evaluating these strategies from NSA and are envisioned to be candidate users of both the
NSA strategy and the architecture introduced in this paper. The final USG approval process for the solution is clearly not required for commercial users, but all other constructs and strategies apply to a broader set of users wishing to have these highly assured secure communications.
The architecture and initial requirements were reviewed against case study responses by experts within the field. Case studies were completed by systems engineers working pathfinder programs for this critical transformational strategy for achieving secure mobile communications for a wide range of users. Lessons learned related to the optimal level of detail in the architecture to support future developments without overly constraining the developers of future secure mobile solutions. The NSA has published much of the program details on a public site that allows for limited constraints on the research. Details of residual risk within composed solutions have been avoided, but the full range of implementation details and strategy for developing solutions are able to be addressed in an open and unconstrained way. All research objectives were able to be met through a methodical look at the wide range of enabling technologies, current systems engineering best practices, and emerging USG policy on the use of commercial for classified communications.
The initial architecture provided a high-level construct for capturing the critical issues within the development of secure mobile. A more comprehensive architecture
120 was required to fully address the wide range of additional details that could be added to address a wider set of users without constraining the solution space. Tailoring of the
DoDAF) is a key enabler for future applications of this approach. The latest version of
DoDAF has a richer set of viewpoints (and views) and can readily support the full range of architectural aspects needing to be addressed. CSfC applications are very limited as this is a new approach and limited case studies are practical, but the range that were available were sufficient to validate the architecture and provide valuable input.
Cost data was minimal as these are new technologies and have limited basis for a comparison. The NSA that implemented legacy secure mobile such as the SME-PED were required to use USG development of both hardware and software that far exceeds the cost of a composed COTS solution. In addition to the cost difference, there are clearly benefits to the end user in getting the latest technology into the hands of the users in the shortest time.
There were several lessons learned from this research activity:
There are many types of architectures – there are frameworks, reference, solution, enterprise, etc. Each one of the types of architectures has many approaches.
There are dozens of architecture frameworks alone. The understanding of the types of architectures early in this research aided me in understanding the various efforts concerning solid taxonomy for this field. Often the approach or strategy for accomplishing the architecture is not as critical as understanding the utility and eventual use of the effort.
121 COTS integration of a wide range of COTS products brings in many
technologies and areas of study - a broad understanding of a large number of
technologies will support understanding greater awareness of the composed solution.
A deep understanding of any component of the architecture is not required to compose
an effective solution. However, leveraging the work of other researchers and agencies
doing work in this area is critical.
Case Studies bring in aspects that were not anticipated during research – the
case study responses brought in observations and understanding of new areas to expand
the architecture that was not anticipated early in the process.
An end-user Focus is Important – when developing an architecture and the
associated templates and views the focus on the end-user of the products is important to
ensure the final product has utility and a solid contribution is made to the field. A
rigorous, systematic, systems engineering approach yields the best results.
Finally, Secure Communications research leveraging work in the Public space by NSA can be accomplished – as long as there is an understanding of the areas to be avoided that are NOT releasable to the public.
Many Potential Applications of CSfC Few have been Explored – there are dozens of applications of CSfC that are envisioned through this research, but only a few mobile smart phone applications have been developed. This research was well received by implementers that have limited guidance as this is a new strategy and are looking for additional guidance. Additionally, this research produced an architecture that is consistent with mature systems engineering best practices and supports a transformative
122 technology that is just now being fielded. The vast range of uses is just now being
understood.
6.2 Limitations
There are several limitations to this research. This technology has just emerged in the past few years and is therefore immature and will clearly evolve over time. There are only a half dozen current implementations to leverage as case studies. Case studies
were able to be gathered for a large percentage of these due to access to these
communications projects, but these case study responses represent an early look at the
issues with secure mobile communications. A long-term look at these implementations could be leveraged to improve the framework.
All the case studies represented projects currently nearing completion, and no projects were available to explore the leveraging of the architecture framework for a new development. This would be a solid test of the utility of the framework. Systems
Engineers clearly would want to leverage an architecture framework for new efforts, but exploring the full dimensions of the utility of architecture frameworks for secure mobile was not possible due to limited access to projects in the planning stages. Case study responses were completed via a single systems engineer supporting the project vice multiple engineers due to limited access to the teams. Clearly a number of completed case study questionnaires from each case (project) would have provided additional perspectives and would have improved the architecture framework.
Finally, some details, such as the risk assessment products from NSA, are classified and provided to USG only. These risk documents supporting the accreditation process were not addressed in this research due to limitations within academic research. Clearly,
123 the NSA capability packages recommend a strategy for limitation of risk, but remaining
risk is addressed in the classified NSA documents.
From NSA website (https://www.nsa.gov/ia/programs/csfc_program/ ):
“USG Customers: Please contact the Client Contact Center
{https://www.nsa.gov/ia/contacts/index.shtml#iccc} link to request a copy of the
associated Risk Assessment.”
6.3 Future Research
Future research areas have been encapsulated by the categories of research summarized in the literature review section above. Some envisioned technologies that will be profound. Additionally, some technologies have most likely not been envisioned that will provide new capabilities for the end users of secure mobile communications.
Threats to Mobile
Threats to mobile technology is a rich area for farther research. These secure mobile solutions should be viewed as targets for collection as they’re protecting classified communications. Each node and component of the architecture could be compromised by a sophisticated adversary. Understanding the evolving threat and conducting research on new techniques is a critical area for future research. These threats and associated system vulnerabilities should be protected to ensure these vulnerabilities are not readily exploited by adversaries before proper mitigation strategies are implemented.
Wireless
Wireless technology includes Wi-Fi, cellular, blue tooth, and technologies that are just now in research and development. Each technology provides a capability in
124 support of the mobile user with a range of attributes that must be understood for the selection and use within a composed solution. Future research in this area could include techniques to seamlessly transition from one media to another or architectures for a standardized framework for a wide range of users to share a standard Wi-Fi access point safely.
Commercial LTE and Vulnerabilities
The current generation (4G) and the future (5G, etc.) are areas for additional research. For systems engineers, understanding the future architectures and leveraging the features of LTE for a wide range of applications is an area for additional research.
Ongoing threats to LTE, such as through jamming, interception, or exploitation, are areas for additional research. Phone technology such as dual SIM cards can enable a single to support classified and unclassified, but additional research is required to fully realize a phone capable of two levels of security. The future of cellular will involve off-loading of traffic to Wi-Fi in both public spaces and home, and research is required to advance these strategies.
Public Key Infrastructure
PKI is managed by each enterprise as the trust of the certification authority is critical to the integrity of the implementation. Research into architectures for cross federated PKI is needed to allow for a trusted bridge across PKI federations. Research on architectures for secure key storage (soft keys) or mechanisms for hardware based certificates that are supported by NFC or other advanced techniques are required.
125 VOIP Secure Calls
Research on improved VOIP security or VOIP functionality to support secure calls is required. Switched telephony has been steadily replaced by VOIP for fixed communications due to improved features at a reduced cost. Strategies for improved
VOIP performance over cellular are required as the vast majority of voice calls are handled by a voice circuits over cellular networks.
Networking
Strategies for routing black (encrypted) traffic over desperate USG networks to include airborne communications networks are required. Research is required to ensure traffic can be routed reliably and networks can peer to effectively transit traffic over a wide range of networks traversing a wide range of transport paths and with each network being managed by different organizations.
Mobile Cloud Services
Research on secure mobile clouds for classified data is required to support a wide range of mobile users. Applications for mobile cloud services exist for standard users, but unique challenges exist for classified traffic and research is required to secure these cloud services.
Smart Grid (and other applications of CSfC)
There are a wide range of applications of the CSfC based approach for secure mobile, including research on additional applications for both architectures and strategies for improved security on the power grid (smart grid) as well as secure communications for telepresence at remote locations worldwide. The advantages of this implementation, in spite of the fact that sensitive crypto graphic equipment is not
126 “in the field” since low cost COTS applications can readily be composed, opens up a wide new range of applications and systems engineering strategies to include architectures for these new and novel applications of this technology.
Commercial Mobile Applied to Tactical Comms
The tactical environment presents unique challenges. The equipment must be hardened to withstand the operating environment, there are limited commercial communications in the field (or they cannot be relied on), which leads to a broader set of USG networks and tactical communications (radios). The CSfC applications can be integrated, but new architectures and strategies are required to support these unique users.
Security Monitoring
Security monitoring strategies from Intrusion Detection Systems (IDS) to Firewalls and improved router technologies; there are a wide range of security appliances that can be applied to composed solutions. The research in this domain is predominantly vendor research on improved products and features. Integrators must be aware of the emerging capabilities and leverage these appliances to yield the most secure implementation at the lowest cost.
Mobile Operating Systems
Trends with mobile operating systems are critical, as the most popular OS will continue to be improved on in terms of security and functionality. The phone vendors couple their products with the OS so an understanding of the emerging trends is critical to planning for the next implementation of a CSfC composed solution. Research in this
127 area focuses more on the study of cyber resilience of the various platforms than on the popularity of various OSs, but the two are clearly related.
Cryptography
As advances in compute technology will render this generations encryption obsolete consistent research is required to ensure are communications are secure into the future.
A higher number of bits, in general, is more secure, but new technology can enhance the security of a cryptographic algorithm. The work in this area is often accomplished within USG labs and agencies, but there is a growing demand in the commercial sector to protect against an increasingly sophisticated threat.
COTS Integration
With the growing use of COTS technologies, there is a need for additional research on strategies for efficient COTS integration. Research on a systems engineering approach to selection, integration, and evaluation is required.
Agile Development
Agile has been applied to software development and has been effective at meeting user’s needs and improving developer efficiencies. The application of agile to other disciplines such as Systems Engineering requires additional research.
Mobile and Legal Issues (and Privacy)
Lawful intercept and communications monitoring techniques are an area for additional research, but these must be constrained by the ethical and legal issues surrounding the application of these technologies/approaches. This research would be focused within a strict policy framework and is often accomplished in the USG domain
128 as they are the users of these techniques and are best able to deal with the policy and legal issues surrounding this work.
Motivation for Research
The threat from an intercept of U.S. critical communications is real. The NSA has developed a strategy for the development of secure communication built entirely on commercial technology. Whether the user is a banker communicating critical financial data or a USG user discussing national security information, USG communications’ professionals can put the latest communications technology from industry in the hands of the critical users now! An architecture for the development of these capabilities can further reduce development times and ensure that proper safeguards are implemented in these communications systems. This begins with secure phones for communications on the move, but novel applications such as secure communications for USG embassies worldwide or secure banking terminals are just some of the transformational capabilities that can be achieved using CSfC technology.
129 Appendix A References
Abdelouahab, Zair, Cláudio Aroucha, Denivaldo Lopes, Jonathan Santos, Willian Ribeiro, and Higo Pires. 2015. “Adaptive Security Mechanism: A Study on the Different Approaches to Mobile Devices.” Journal of Information Sciences and Computing Technologies 2 (2): 147–53.
Abts, C., B. W. Boehm, and E. B. Clark. 2000. “COCOTS: A COTS Software Integration Lifecycle Cost Model-Model Overview and Preliminary Data Collection Findings.” ESCOM-SCOPE Conference. Citeseer. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.31.8295&rep=rep1&type =pdf.
Ackerman, Robert. 2015. “Marines Strive for Holistic Network Improvements.” Signal, December. www.afcea.org/signal.
Albert, Cecilia, and Lisa Brownsword. 2002. “Evolutionary Process for Integrating COTS-Based Systems (EPIC): An Overview.” CMU/SEI-2002-TR-009. Software Engineering Institute. http://resources.sei.cmu.edu/library/asset- view.cfm?assetID=6093.
Alexander, Susan D. 2012. “Trust Engineering: Rejecting the Tyranny of the Weakest Link.” In Proceedings of the 28th Annual Computer Security Applications Conference, 145–48. ACSAC ’12. New York, NY, USA: ACM.
Alfandi, Omar, Arne Bochem, Ansgar Kellner, Christian Göge, and Dieter Hogrefe. 2015. “Secure and Authenticated Data Communication in Wireless Sensor Networks.” Sensors 15 (8): 19560–82.
Althouse, Mlg. 2015. “I Want My Smartphone. I Want It Now. And I Want to Connect to Everything from Anywhere… Now!” Warfare 14. nsa.gov: 86–97.
Bailey, David. 2014. “The Difficulty of Securing Your Mobile Workforce.” Computer Fraud & Security 2014 (9): 19–20.
Becher, M., F. C. Freiling, J. Hoffmann, T. Holz, S. Uellenbeck, and C. Wolf. 2011. “Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices.” In Security and Privacy (SP), 2011 IEEE Symposium on, 96–111. ieeexplore.ieee.org.
Bellovin, Steven M., Matt Blaze, Sandy Clark, and Susan Landau. 2014. “Lawful Hacking: Using Existing Vulnerabilities for Wiretapping on the Internet.” Nw. J. Tech. & Intell. Prop. 12. HeinOnline: i.
A-1 Bellovin, Steven Michael, Matt Blaze, Ernest Brickell, Clinton Brooks, Vinton Cerf, Whitfield Diffie, Susan Landau, Jon Peterson, and John Treichler. 2006. “Security Implications of Applying the Communications Assistance to Law Enforcement Act to Voice over IP.” ITAA. https://www.cs.columbia.edu/~smb/papers/CALEAVOIPreport.pdf.
Bezzera, Julio. 2015. “The Mobile Revolution: How Mobile Technologies Drive a Trillion Dollar Industry.” Boston Consulting Group. https://www.bcgperspectives.com/content/articles/telecommunications_technology_ business_transformation_mobile_revolution/.
Bilgin, B., B. Gierlichs, S. Nikova, V. Nikov, and V. Rijmen. 2015. “Trade-Offs for Threshold Implementations Illustrated on AES.” IEEE Transactions on Computer- Aided Design of Integrated Circuits and Systems 34 (7): 1188–1200.
Boehm, B., and C. Abts. 1999. “COTS Integration: Plug and Pray?” Computer 32 (1): 135–38.
Bowman, Ltg Mark. 2013. “Emerging Technologies and the Joint Staff.” June 20. http://www.ndia.org/Resources/OnlineProceedings/Documents/21M0/MODSIM/03 -Defense-Hunt.pdf.
Boyens, Jon M., Celia Paulsen, Rama Moorthy, and Nadya Bartol. 2015. “Supply Chain Risk Management Practices for Federal Information Systems and Organizations.” National Institute of Standards and Technology. doi:10.6028/NIST.SP.800-161.
Boyle, M. 2014. “Information Assurance Standards: A Cornerstone for Cyber Defense.” Journal of Information Warfare 13 (April). https://www.jinfowar.com/.
Braga, Alexandre Melo, Daniela Castilho Schwab, Eduardo Moraes de Morais, Romulo Zanco Neto, and André Luiz Vannucci. 2015. “Integrated Technologies for Communication Security and Secure Deletion on Android Smartphones.” International Journal on Advances in Security Volume 8, Number 1 & 2, 2015. iariajournals.org. http://www.iariajournals.org/security/sec_v8_n12_2015_paged.pdf#page=36.
Braun, T., and M. Danzeisen. 2001. “Secure Mobile IP Communication.” In Local Computer Networks, 2001. Proceedings. LCN 2001. 26th Annual IEEE Conference on, 586–93.
Brown, Kurt. 2015. “ENHANCING BATTLEFIELD COMMUNICATIONS THROUGH 4G LTE+ CELLULAR TECHNOLOGY.” Journal of Battlefield Technology 18 (3). http://www.argospress.com/jbt/18/3/enhancing-battlefield- communications-through-4g-lte-cellular-technology.
A-2 Buibish, A-M, N. E. Johnson, D. Emery, and M. Prudlow. 2011. “Cryptographic Solutions for COTS Smart Phones.” In MILITARY COMMUNICATIONS CONFERENCE, 2011 - MILCOM 2011, 1434–39. ieeexplore.ieee.org.
CACI. 2015. “Wireless Remote Authenticated Tactical Handheld (WRATH).” https://www.caci.com/sas15/pdf/wrath_secure_smartphone_communications.pdf.
Chang, Woojung, Alexander E. Ellinger, and Jennifer Blackhurst. 2015. “A Contextual Approach to Supply Chain Risk Mitigation.” The International Journal of Logistics Management, October. Emerald Group Publishing Limited. doi:10.1108/IJLM-02- 2014-0026.
Chuang, Yu-Hao, Chien-Lung Hsu, Wesley Shu, Kevin C. Hsu, and Min-Wen Liao. 2015. “A Secure Non-Interactive Deniable Authentication Protocol with Certificates Based on Elliptic Curve Cryptography.” In New Trends in Intelligent Information and Database Systems, 183–90. Studies in Computational Intelligence. Switzerland: Springer International Publishing.
Clancy, T. C., M. Norton, and M. Lichtman. 2013. “Security Challenges with LTE- Advanced Systems and Military Spectrum.” In Military Communications Conference, MILCOM 2013 - 2013 IEEE, 375–81. ieeexplore.ieee.org.
Clark, John. 2009. “System of Systems Engineering and Family of Systems Engineering From a Standards, V-Model, and Dual-V Model Perspective.” In IEEE SysCon 2009 —3rd Annual IEEE International Systems Conference, 2009. http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4815831&url=http%3A%2F %2Fieeexplore.ieee.org%2Fiel5%2F4813824%2F4815755%2F04815831.pdf%3Fa rnumber%3D4815831.
Cloutier, Robert, Gerrit Muller, Dinesh Verma, Roshanak Nilchiani, Eirik Hole, and Mary Bone. 2010. “The Concept of Reference Architectures.” Systems Engineering 13 (1). Wiley Subscription Services, Inc., A Wiley Company: 14–27.
Committee on National Security Systems. 2012. “Security Categorization and Control Selection for National Security Systems.” CNSS Instruction No. 1253. https://www.cnss.gov/CNSS/issuances/Instructions.cfm.
Committee on National Security Systems. 2013. “NATIONAL POLICY GOVERNING THE ACQUISITION OF INFORMATION ASSURANCE (IA) AND IA- ENABLED INFORMATION TECHNOLOGY PRODUCTS.” Citeseer. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.361.4635&rep=rep1&typ e=pdf.
Consolvo, Sunny. 2015. “Privacy and Security.” Pervasive Computing, March. Psychology Press, 17.
A-3 Cuevas, A., J. I. Moreno, P. Vidales, and H. Einsiedler. 2006. “The IMS Service Platform: A Solution for next-Generation Network Operators to Be More than Bit Pipes.” IEEE Communications Magazine 44 (8): 75–81.
Dar, Kamran Shaukat, Imran Javed, Syed Asad Ammar, Syed Konain Abbas, Sohail Asghar, M. Abu Bakar, and Usman Shaukat. 2015. “A Survey-Data Privacy through Different Methods.” Journal of Network Communications and Emerging Technologies (JNCET) Www. Jncet. Org 5 (2). jncet.org. http://www.jncet.org/Manuscripts%5CVolume-5%5CIssue-2%5CVol-5-issue-2-M- 01.pdf.
Dar, Muneer Ahmad, and Javed Parvez. 2014. “A Novel Strategy to Enhance the Android Security Framework.” International Journal of Computer Applications in Technology 91 (8). Foundation of Computer Science. http://search.proquest.com/openview/56f793309520a4be62135580030d56a7/1?pq- origsite=gscholar.
Das, S., V. Kaul, Jaewon Kang, K. Sinkar, D. Chee, S. Samtani, B. D. Foresta, N. W. Reis, P. B. Wiener, and T. G. Sepka. 2013. “Realizing Secure Cellular and Mobile Hot-Spot Extension to Tactical Networks.” In Military Communications Conference, MILCOM 2013 - 2013 IEEE, 674–79.
Davis, Kim, Thomas Mazzuchi, and Shahram Sarkani. 2013. “Architecting Technology Transitions: A Sustainability-Oriented Sociotechnical Approach.” Systems Engineering 16 (2). Wiley Subscription Services, Inc., A Wiley Company: 193– 212.
Dawson, Maurice, Jorja Wright, and Marwan Omar. 2015. “Mobile Devices: The Case for Cyber Security.” New Threats and Countermeasures in Digital Crime and Cyber Terrorism. IGI Global, 8.
Defense Science Board. 2009. “Buying Commercial: Gaining the Cost/Schedule Benefits for Defense Systems.” Department of Defense. http://www.acq.osd.mil/dsb/reports/ADA494760.pdf.
Department of Defense. 2011. “DoD/VA Integrated Enterprise Portal Reference Architecture.” https://frectal.files.wordpress.com/2011/10/iehr_portal_architecture_1slide.pdf.
Department of Defense. 2013. “Commercial Mobile Device Implementation Plan.” Department of Defense. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.400.8054&rep=rep1&typ e=pdf.
Department of Defense. 2013. “Unified Capabilities Reference Architecture.” Version 1.0. DOD. http://dodcio.defense.gov/Portals/0/Documents/DIEA/Approved%20DoD%20UC% 20Reference%20Architecture.pdf.
A-4 Department of Energy. 2013. “Department of Energy National Laboratories and Plants Mobility Across the Complex.” http://www.nrel.gov/docs/fy13osti/60062.pdf.
Department of Homeland Security. 2011. “Telework Reference Architecture.” Version 1.0. DHS. https://www.telework.gov/training-resources/federal-resources/agency- guidance/.
Dukes, Mr Curtis W. 2013. “Trusted Platforms Presentation.” presented at the AFCEA West 2013, San Diego Convention Center, January 29. http://www.afcea.org/events/west/13/documents/TrustedPlatformsDukes.pdf.
Dynamics, General. 2013. “GD ProtectedTM Mobile Solutions for Selected Samsung GALAXY Smartphones.” General Dynamics. http://www.prnewswire.com/news- releases/general-dynamics-to-deliver-enhanced-security-for-samsung-mobile- devices-193034151.html.
Eng, Siv Fern. 2014. “Agility and Discipline A Case Study in Incorporating More Balance to a Software Engineering Process.” Portland State University. http://syse.pdx.edu/program/portfolios/siv/sivfinalproj.pdf.
Epstein, Robert J. 2014. “Policy and Policy Formulation Considerations for Incorporation of Secure Mobile Devices in USMC Ground Combat Units.” Monterey, California: Naval Postgraduate School. http://calhoun.nps.edu/handle/10945/43908.
Evans, Rhys, Evans Rhys, Tsohou Aggeliki, Tryfonas Theo, and Morgan Thea. 2010. “Engineering Secure Systems with ISO 26702 and 27001.” In 2010 5th International Conference on System of Systems Engineering. doi:10.1109/sysose.2010.5544065.
Federal Bridge Certification Authority. 2013. “X.509 Certificate Policy For The Federal Bridge Certification Authority (FBCA).” Version 2.27. https://pki.treas.gov/docs/x509_certificate_policy_for_the_federal_bridge_certificat ion_authority.pdf.
Federal CIO Council and Department of Homeland Security. 2013. “Mobile Security Reference Architecture.” V1.0. Federal CIO Council and DHS. https://cio.gov/wp- content/uploads/downloads/2013/05/Mobile-Security-Reference-Architecture.pdf.
Federal CIO Council. 2013. “Adoption of Commercial Mobile Applications within the Federal Government Digital Government Strategy Milestone 5.4.” Federal CIO Council. https://cio.gov/wp-content/uploads/downloads/2013/05/Commercial- Mobile-Application-Adoption-DGS-Milestone-5.4.pdf.
Fitton, C., C. Sandler, and T. Badgett. 2012. Enterprise Mobility for Dummies.
Gamez, N., L. Fuentes, and J. M. Troya. 2015. “Creating Self-Adapting Mobile Systems with Dynamic Software Product Lines.” Software, IEEE 32 (2): 105–12.
A-5 Girard, John, Dionisio Zumerle, and Rob Smith. 2015. “Critical Capabilities for High- Security Mobility Management.” Gartner. http://www.gartner.com/.
Gnanasankaran, N., K. Iyakutti, K. Alagarsamy, and S. Natarajan. 2015. “The Impact of COTS Components on Software Quality in IT Industry: A Survey and Its Analysis.” Issues 1 (1): 1–10.
Grayeli, Parisa, Shahram Sarkani, and Thomas Mazzuchi. 2012. “Performance Analysis of IPv6 Transition Mechanisms over MPLS.” International Journal of Communication Networks and Information Security (IJCNIS) 4 (2). http://www.ijcnis.org/index.php/ijcnis/article/view/155.
Gump, Jamieson W. OCTOBER 30, 2014. “An Architecture for Agile Systems Engineering of Secure Commercial-off-the Shelf (COTS) Mobile Communications.” presented at the 17th ANNUAL SYSTEMS ENGINEERING CONFERENCE, Springfield, VA. http://www.dtic.mil/ndia/2014system/16845ThursTrack6Gump.pdf.
Hasan, Basel, Tariq Mahmoud, Jorge Marx Gómez, Reshmi Pramod, and Joachim Kurzhöfer. 2015. “User Acceptance Identification of Restrictions Caused by Mobile Security Countermeasures.” MOBILITY 2015. researchgate.net, 39.
Hernon, Mike. July – September 2011. “Going Mobile: News from the DON Mobility Program.” CHIPS. www.chips.navy.mil.
Heron, Simon. 2009. “Advanced Encryption Standard (AES).” Network Security 2009 (12): 8–12.
Hicks, J. Marcus. 2015. “A Theater-Level Perspective on Cyber.” DTIC Document. http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA6 18537.
Holbert, Mike. Sep-Oct 2011. “Systems Engineering: The Affordability Secret Weapon.” Defense AT&L: Better Buying Power. http://www.dtic.mil/cgi- bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA564351.
Houck, Carol. 2011. “National Information National Information Assurance Partnership Assurance Partnership.” presented at the Information Security and Privacy Advisory Board (ISPAB), Homewood Suites by Hilton D.C., 1475 Massachusetts Avenue, NW, Washington, DC 20005, July 13. http://www.engr.psu.edu/ae/thesis/portfolios/2011/deh5043/Houck_FinalPresentati on.pptx.
Hughes, Alexandra. 2015. “Android Mobile Security: A Comprehensive Evaluation of Its Feats and Flaws.” UTICA COLLEGE. http://gradworks.umi.com/15/86/1586570.html.
A-6 Hutchison, J., and R. Coia. 2013. Protected mode for securing computing devices. US Patent App. 13/967,156, issued 2013. https://www.google.com/patents/US20150052616.
Ionescu, Valeriu, Ionescu Valeriu, Sima Ion, Diaconu Adrian-Viorel, and Stan Valentin. 2012. “Security Communications Interoperability Protocol Implementation.” In 2012 9th International Conference on Communications (COMM). doi:10.1109/iccomm.2012.6262534.
Jain, Rashmi, Anithashree Chandrasekaran, and Ozgur Erol. 2010. “A Systems Integration Framework for Process Analysis and Improvement.” Systems Engineering 13 (3). Wiley Subscription Services, Inc., A Wiley Company: 274–89.
Jharbade, Nitin K., and Rajesh Shrivastava. Sept-Oct 2011. “Network Based Security Model Using Symmetric Key Cryptography (AES-256-Rijndael Algorithm) with Public Key Exchange Protocol (Diffie-Hellman Key Exchange Protocol).” International Journal of Advanced Research in Computer Science 2 (5). www.ijarcs.info.
Jones, Analyst :. Nick. 2014. “Top 10 Mobile Technologies and Capabilities for 2015 and 2016.” Gartner. http://www.gartner.com/.
Jones, Nick. 2015. “Top 10 Mobile Technologies and Capabilities, 2015 Status Update.” Gartner. http://www.gartner.com/.
Jones, Rick A., and Barry Horowitz. 2012. “A System-Aware Cyber Security Architecture.” Systems Engineering 15 (2). Wiley Subscription Services, Inc., A Wiley Company: 225–40.
Joshi, M. R., and Bhagyashri V. Tikar. 2015. “Cloud-Computing Its Services and Resent Trends.” International Journal of Computer Science and Mobile Computing. http://ijcsmc.com/docs/papers/February2015/V4I2201540.pdf.
Jousselme, Anne-Laure, Kevin Huggins, Nicolas Léchevin, Patrick Maupin, and Dominic Larkin. 2013. “Vulnerability-Aware Architecture for a Tactical, Mobile Cloud.” In Complex Networks, 57–65. Studies in Computational Intelligence. Springer Berlin Heidelberg.
Jueneman, Robert. 2013. “Trusted Mobility Solutions to Software Encryption Compromises.” SPYRUS. www.spyrus.com/.
Juniper Networks. 2013. “ENVISIONING THE FUTURE OF SECURE COMMUNICATIONS.” http://www.juniper.net/assets/us/en/local/pdf/whitepapers/2000513-en.pdf.
Jürjens, Jan, and Jürjens Jan. 2002. “UMLsec: Extending UML for Secure Systems Development.” In Lecture Notes in Computer Science, 412–25.
A-7 Flora, K., Harleen, K. Flora Harleen, Swati V. Chande, and Wang Xiaofeng. 2014. “Adopting an Agile Approach for the Development of Mobile Applications.” International Journal of Computer Applications in Technology 94 (17): 43–50.
Keller, John. 12/2011. “Crypto Modernization Transforms Military Communications.” MILITARY & AEROSPACE ELECTRONICS. http://www.militaryaerospace.com/articles/print/volume-22/issue-12/special- report/crypto-modernization-transforms-military-communications.html.
Kiehl, Thorsten, and Ralf God. 2013. “An MBSE-Approach for Using Near Field Communication in the Aircraft Cabin.” In Proceedings of the 4th International Workshop on Aircraft System Technologies, 333–54.
Kindamo, Brian. 5/2014. “Practical Applications for Advanced Electronics.” Military Technology. http://www.monch.com/mpg/index.php.
King, D., G. Orlando, and J. Kohler. 2012. “A Case for Trusted Sensors: Encryptors with Deep Packet Inspection Capabilities.” In MILITARY COMMUNICATIONS CONFERENCE, 2012 - MILCOM 2012, 1–6. ieeexplore.ieee.org.
Lago-Fernández, J., F. Gil-Castiñeira, F. J. González-Castaño, and A. Román- Portabales. 2014. “A New Approach to Authenticating and Encrypting Voice over Internet Protocol Communications.” Software: Practice & Experience 44 (5): 593– 619.
Landau, Susan. 2014. “Under the Radar: NSA’s Efforts to Secure Private-Sector Telecommunications Infrastructure.” J. Nat’l Sec. L. & Pol'y 7. HeinOnline: 411.
Le Master, Tim. 2013. “What Suite B Means to the Defense, Intelligence and Law Enforcement Communities.” The Modern Network. May 23. http://themodernnetwork.com/government/what-suite-b-means-to-the-defense- intelligence-and-law-enforcement-communities/.
Leavitt, N. 2005. “Mobile Phones: The next Frontier for Hackers?” Computer 38 (4). ieeexplore.ieee.org: 20–23.
Leavitt, N. 2011. “Mobile Security: Finally a Serious Problem?” Computer 44 (6). ieeexplore.ieee.org: 11–14.
Li, Qing, and G. Clark. 2013. “Mobile Security: A Look Ahead.” Security Privacy, IEEE 11 (1). ieeexplore.ieee.org: 78–81.
Lim, Kyung-Soo, Su-Wan Park, Jeong-Nye Kim, and Deok-Gyu Lee. 2015. “Functional Considerations in Military-Grade Security Platform Using a Mobile Hypervisor.” In Computer Science and Its Applications, 1413–18. Lecture Notes in Electrical Engineering. Springer Berlin Heidelberg.
A-8 Lindteigen CISSP, Ty B., and Chief Technology Officer. 2014. “Military Data Storage Security.” http://saifeinc.com/static/papers/saife-military_data_storage.pdf.
Mahmood, Anzar, Nadeem Javaid, and Sohail Razzaq. 2015. “A Review of Wireless Communications for Smart Grid.” Renewable and Sustainable Energy Reviews 41 (January): 248–60.
Mahon, Tim. 10/2015. “Crypto Technology in the Digital Age.” Military Technology. http://www.monch.com/mpg/index.php.
Marcus Hicks, J. 2015. “A Theater-Level Perspective on Cyber.” JFQ 76, October. http://ndupress.ndu.edu/Portals/68/Documents/jfq/jfq-76/jfq-75_58-63_Hicks.pdf.
Martinez, Christopher, and Robert Haverkos. 2014. “Commercial Solutions for Classified (CSfC), Risk Analysis.” http://insurehub.org/sites/default/files/reports/Risk%20Analysis_CSfC%20Final%2 0Report%20Christopher%20%20Robert.pdf.
McAfee and Harris Corp. 2013. “Security for Military-Grade Google Android Devices.” http://www.mcafee.com/.
Meaux, Paul. 2013. “NSA Implementing New Commercial Strategy.” Army Communicator 38 (2). http://www.signal.army.mil/index.php/sigcoe/directorates/ocos/army- communicator.
Meissen, U., and A. Voisard. 2010. “Towards a Reference Architecture for Early Warning Systems.” In Intelligent Networking and Collaborative Systems (INCOS), 513–18.
Minkiewicz, Arlene. 2006. “Six Steps to a Successful COTS Implementation.” Quality Assurance Institute, Orlando, FL, January. http://www.compaid.com/caiinternet/ezine/COTS-AM.pdf.
Mocano. 2012. “Amphion Forum: Meeting NSA’s Mobile Capability Requirements: Secure VoIP on COTS Smartphones.” June. https://www.fbcconferences.com/e/IAS/agendagrid.aspx.
Moses, Kuboye Bamidele. 2014. “Mobile Communication Evolution.” International Journal of Modern Education and Computer Science (IJMECS) 6 (1): 25.
Motorola. 2012. “COMMERCIAL SMARTPHONES. CLASSIFIED COMMUNICATIONS. COMPLETE SECURITY. TOP CONSIDERATIONS FOR TRUE MOBILE SECURITY.” http://video.motorolasolutions.com/video.aspx/commercial-devices-classified- communications-complete-security/1780294298001%20.
A-9 Moujaes, Eric. 2013. “Mobile Industry Statistics.” Phunware. June 1. http://www.phunware.com/blog/mobile-statistics/.
Murphy, B., A. Akinpelu, A. Desimone, and J. Forte. 2013. “Sharktank: The SeCAN Lab;Tip of the Spear; for Commercial Solutions for Classified Mobility Systems.” In Military Communications Conference, MILCOM 2013 - 2013 IEEE, 1377–82.
National Security Agency. 2015. “Commercial Solutions for Classified.” National Security Agency Public Site. Accessed July 25. https://www.nsa.gov/ia/programs/csfc_program/.
Nazeer, Sumat, Faisal Bahadur, Arif Iqbal, Ghazala Ashraf, and Shahid Hussain. 2015. “A Comparison of Window 8 and Linux Operating System (Android) Security for Mobile Computing.” International Journal of Computer (IJC) 17 (1). ijcjournal.org: 21–29.
Nekoui, Ashley. 2012. “Maas Secure Mobile Communications for Warfighters.” Technology Review. http://www.doncio.navy.mil/CHIPS/ArticleDetails.aspx?ID=5270.
Oberheide, Jon, and Farnam Jahanian. 2010. “When Mobile Is Harder Than Fixed (and Vice Versa): Demystifying Security Challenges in Mobile Environments.” In Proceedings of the Eleventh Workshop on Mobile Computing Systems & Applications, 43–48. HotMobile ’10. New York, NY, USA: ACM.
Office of Navel Research. 2012. “Mobile Security Architecture (MSA).” DON. http://www.onr.navy.mil/en/Media-Center/Fact-Sheets/Mobile-Architecture- Security.aspx.
Onnela, J-P, J. Saramäki, J. Hyvönen, G. Szabó, D. Lazer, K. Kaski, J. Kertész, and A- L Barabási. 2007. “Structure and Tie Strengths in Mobile Communication Networks.” Proceedings of the National Academy of Sciences of the United States of America 104 (18): 7332–36.
Parker, Stephen. 2014. “Mobile Information.” Information Development 30 (1): 3–5.
Plunkett, D. A. 2014. “Achieving Confidence in Cyberspace in an Ever-Changing Ecosystem.” Journal of Information Warfare Volume 13 (2 April 2014). https://www.jinfowar.com/.
Pratap, Analyst :. Khushbu, and Dionisio Zumerle. 2015. “Introducing the Mobile Security Assessment and Audit Framework.” Gartner. http://www.gartner.com/.
QUALCOMM. 2012. “Circuit Switched Fallback The-First Phase of Voice Evolution for Mobile LTE Devices.” https://www.qualcomm.com/media/documents/files/circuit-switched-fallback-the- first-phase-of-voice-evolution-for-mobile-lte-devices.pdf.
A-10 Quarles, H. Keith. 2012. “Use of Simplified DoDAF Viewpoints to Improve Dynamic Emergency Management through Intelligence Surveillance and Reconnaissance.” The George Washington University. http://search.proquest.com/docview/993153620.
Rashmi, V. R., and Sneha Johnson. 2015. “Security in Mobile: A Survey.” In IJCA Proceedings on International Conference on Advanced Computing and Communication Techniques for High Performance Applications, 24–29. Foundation of Computer Science (FCS).
Rasmussen, Jeremy. 2012. “Just Don’t Take Away My Smartphone.” An Institute of Land Warfare Publication. ausar-web01.inetu.net. http://ausar- web01.inetu.net/publications/ilw/ilw_pubs/landpoweressays/Documents/LPE_12- 1_web.pdf.
Raychaudhuri, D., and Narayan B. Mandayam. 2012. “Frontiers of Wireless and Mobile Communications.” Proceedings of the IEEE 100 (4): 824–40.
Raytheon. 2013. “Trusted Thin Client Multi-Enterprise Network Spanning Bridging the Gap between Enterprises with the next Step in Secure Information Access A Future Capability Concept White Paper.” Raytheon. http://www.milcis.com.au/milcis2012- program.
Refaei, M. T., and J. Bush. 2014. “Secure Reliable Group Communication for Tactical Networks.” In Military Communications Conference (MILCOM), 2014 IEEE, 1195–1200. ieeexplore.ieee.org.
Rittenbach, T., H. Satake, D. Schoonmaker, J. Cunningham, and T. Duffe. 2013. “A Government Reference Architecture Test Bed Using a Virtual Private Network.” In Military Communications Conference, MILCOM 2013 - 2013 IEEE, 1768–73.
Roeper, Fred, and Ziring, Neal, National Security Agency. 2012. “Building Robust Security Solutions Using Layering And Independence.” presented at the RSA Conference, Moscone Center, San Francisco , March 2. http://www1.rsaconference.com/writable/presentations/file_upload/star-401.pdf.
Roos, A., M. Hartman, and S. Dutnall. 2003. “Critical Issues for Roaming in 3G.” IEEE Wireless Communications 10 (1): 29–35.
Saini, Neelima, and Sunita Mandal. 2015. “Review Paper on Cryptography.” International Journal of Research (IJR) 2 (5). http://internationaljournalofresearch.org.
Sanders, Gary A., Shahram Sarkani, and Thomas Mazzuchi. 2013. “High Consequence Systems Phenomenological Characterization: A Tutorial.” Systems Engineering 16 (4). Wiley Subscription Services, Inc., A Wiley Company: 464–72.
A-11 Schechner, Sam. 2014. “French Contractors Jump Into Market for Secure Communications.” WSJ Online Article, January 1. http://www.wsj.com/articles/SB10001424052702304591604579292222768536610.
Seffers, George. 2015. “Information Flows at Pacific Command’s Synchronization Hub.” Signal, November. http://www.afcea.org/content/?q=Article-information- flows-pacific-command%E2%80%99s-synchronization-hub.
Sefid-Dashti, Behrouz, and Jafar Habibi. 2014. “A Reference Architecture for Mobile SOA.” Systems Engineering 17 (4): 407–25.
Simanta, S., G. A. Lewis, E. Morris, Kiryong Ha, and Mahadev Satyanarayanan. 2012. “A Reference Architecture for Mobile Code Offload in Hostile Environments.” In Software Architecture (WICSA) and European Conference on Software Architecture (ECSA), 2012 Joint Working IEEE/IFIP Conference on, 282–86.
Singh, A., P. Mudholkar, and L. L. Balani. 2015. “Contemporary Enterprise Architecture Frameworks.” In Conference: ICAIM-International Conference on Advancement in IT and Management. http://www.researchgate.net/profile/Alok_Singh26/publication/271079220_Contem porary_Enterprise_Architecture_Frameworks_(A_Comparative_study_of_TOGAF _and_Zachmans’_EA_frameworks)/links/54bdd68e0cf27c8f2814d2b6.pdf.
Smalley, Stephen. 2013. “Laying a Secure Foundation for Mobile Devices.” In NDSS. incose-cc.org. http://www.incose-cc.org/http://www.incose- cc.org/images/LayingASecureFoundation-Smalley-2013-08.pdf.
Smith, Matthew, Christian Schridde, Björn Agel, and Bernd Freisleben. 2010. “Secure Mobile Communication via Identity-Based Cryptography and Server-Aided Computations.” The Journal of Supercomputing 55 (2). Springer US: 284–306.
Specialists, Information Assurance. 2015. “IAS Small Tactical Executive WAN.” http://www.iaspecialists.com/docs/IAS_STEW_1.pdf.
Stevens, R., P. Brook, K. Jackson, and S. Arnold. 1998. Systems Engineering: Coping with Complexity. Prentice-Hall, London.
Suder, Tom. 2015. “Computing Summit Collaboration Session Summary.” http://www.atarc.org/wp-content/uploads/2015/06/MITRE-ATARC-Mobile-White- Paper-February-20151.pdf.
Tang, Longji, Fed Ex, Wei-Tek Tsai, and Jing Dong. 2013. “Enterprise Mobile Service Architecture: Challenges and Approaches.” Service Technology Magazine Issue LXXIX (December 2013). http://www.servicetechmag.com/I79/1213-3.
A-12 The Open Group. 2004. “Secure Mobile Architecture (SMA) Vision and Architecture.” The Open Group. https://www.researchgate.net/publication/224248207_Comparison_and_Analysis_o f_Secure_Mobile_Architecture_SMA_and_Evolved_Packet_System.
Unewisse, Mark, Shaun Wilson, Anthony Perry, and Cameron Boyd. 2006. “An Australian Approach to Assessing Force-Level Network-Centric Warfare (NCW) Readiness.” In 11th ICCRTS. http://www.dodccrp.org/events/2006_CCRTS/html/papers/085.pdf.
US Army. 2013. “Army Mobility Strategy.” US Army. http://ciog6.army.mil/Portals/1/Policy/2013/Army%20Mobility%20Strategy_26NO V2013.pdf.
US Government. 1999. “Recommended Elliptic Curves for Federal Government Use.” National Institute for Standards. http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf.
Väisänen, Teemu, Alexandria Farar, Nikolaos Pissanidis, Christian Braccini, Bernhards Blumbergs, and Enrique Diez. 2015. “Defending Mobile Devices for High Level Officials and Decision-Makers.” Ccdcoe.org. https://ccdcoe.org/sites/default/files/multimedia/pdf/Defending%20mobile%20devi ces%20for%20high%20level%20officials%20and%20decision-makers.pdf.
Various. 2012. Regulation and the Evolution of the Global Telecommunications Industry. Edited by Anastassios Gentzoglanis, University of Sherbrooke, Canada and Anders Henten, Aalborg University, Denmark. Edward Elgar Publishing Limited.
Viasat. 2013. “Trusted Networking & Cybersecurity.” Viasat. https://www.viasat.com/sites/default/files/legacy/web/datasheets/SNS_Overview_br ochure_012_web.pdf.
Waddell, Joshua C. 2014. “Leveraging Manet and Mobile Devices in Ship-to-Objective Maneuver and Expeditionary MAGTF Operations.” Monterey, California: Naval Postgraduate School. http://calhoun.nps.edu/handle/10945/44026.
Walker, Amy. 2014. “WIFI Hits the Battlefield.” Army Communicator 39 (2): 16.
Windelberg, Marjorie. 2015. “Objectives for Managing Cyber Supply Chain Risk.” International Journal of Critical Infrastructure Protection. Elsevier. doi:10.1016/j.ijcip.2015.11.003.
Zage, John, Robert Wells, and Marsella Farnam. 2015. “TECH 581: Problems in National Security: Final Report.” Insurehub.org. http://insurehub.org/sites/default/files/reports/Purdue-Zage-Farnam-Wells-final- report%20.pdf.
A-13 Zhang, Xinwen, Onur Aciiçmez, and Jean-Pierre Seifert. 2007. “A Trusted Mobile Phone Reference Architecture via Secure Kernel.” In STC ’07 Proceedings of the 2007 ACM Workshop on Scalable Trusted Computing, 7–14. NY, NY: ACM.
Zumerle, Analyst :. Dionisio, and John Girard. 2015. “Hype Cycle for Enterprise Mobile Security, 2015.” Gartner. http://www.gartner.com/.
A-14 Appendix B Case Study Questions
Instructions Section
Research Topic: An Architecture for Agile Systems Engineering of Secure
Commercial-off-the-Shelf Mobile Communications
This research is to develop an architecture for Secure Mobile Communications.
The Commercial Solutions for Classified (CSfC) program managed by the National
Security Agency (NSA) provides capability packages for various implementations of secure mobile comms leveraging COTS. This research is to extend the CSfC architecture to provide a broader comprehensive architecture framework to support the broad range of end user applications.
To support the research, case studies will be conducted on a range of applications to validate the draft Architecture (see other tab).
I have used Excel to gather the data to ease integration into a comprehensive framework.
If you prefer verbal responses to these questions I can schedule an interview to meet with you. Also, if you have any documents that support the responses and you can provide them please forward with this sheet.
Please call or e-mail with any questions, Thanks, Jim ([email protected])
Part Time: PhD (Systems Engineering) Student at George Washington University
Full Time: Assistant Program Area Manager at the Johns Hopkins University
Applied Physics Lab (JHU APL) [I support related work so JHU APL and Government
Clear any Publications]
Secure Mobile Survey
B-1
Version .2 Jim Gump (PhD Student, Systems Engineering, George Washington University) Questions Short Title Additional Notes A Tell me about you 1 Name 2 Office 3 Email Address 4 Follow-up Can I contact you for follow-up information? 5 Recommendations Do you have any recommended changes for the survey? 6 Assist in Arch Dev Would you agree to reviewing a draft architecture that results from these case studies/surveys and providing recommended changes? B Capability Overview 1 Capability Name Name of the Capability 2 Version Version of the Capability 3 Summary Description Summarize the secure communications implementation (s) you are currently developing. 4 Stakeholders High level summary of stakeholders 5 Program Phase Summarize the phase of the program 1) requirements, 2) development, 3) sustainment, etc. 6 User Demand Summary of the user demand for the capability. 7 User Demand - Quantified Score from 1 to 5 (1 is low, 5 is high) 8 Known Limitations Summarize any limitations that exist in the capability. C. Specific Questions (Architecture) 1 Enterprise Benefits (What are the high level benefits of your capability) a Summary Summarize benefits of your capability b Cost Savings Summarize cost savings over legacy capabilities (is your implementation all COTS?) c Time to Field Summarize the time to field a capability (months to from design to fielding d Loss of devices Summarize organizational policy wrt loss of a device (and contrast with legacy controlled cryptographic items - CCI) e Mobile Device Mgr Mobile Device Manager (MDM) to manage all devices from a single console (or software application). 2 Enterprise Requirements/Policy a High Level Requirements Users
B-2
Summary Summarize the users of the capability. Summarize the implementation dependencies or relationship to related activities. How Authenticated How are users authenticated (Fingerprint, CAC Card, Password, etc.)? Enterprise Extended What named enterprise capabilities are brought to the mobile edge (JWICS, SIPR, Summary HSDN, etc.) Features What are the specifics of the enterprise services (voice, video and data)? Device What device (s) have you selected? Summary (Samsung Phone, etc.) Transport Supported What transport (cell, Wi-Fi, etc.)? Operating Locations Summary Aircraft, Vehicle, public Wi-Fi OCONUS CONUS only, OCONUS? b Existing Policy Describe any Policy or regulatory concerns. (Wi-Fi in a SCIF, SCI outside a SCIF, etc.) c Policy Changes Recommended changes to policy. d Priority Services Efforts relating to priority services over cellular (and Wi-Fi)? 3 User Experience a Classification Lvls What Classification Level can the user speak at? (Secret, TS, etc.) b Class. Desires What Classification Level does the user want to speak at? c Voice Quality What is the quality of the voice call (do you have PESQ scores)? d Ease of Use Does the user have "one button dial" … other features? Issues with initial fielding? 4 Transport a Summary Expand on above, how is the transport implemented (cellular contract, with dedicated comms back to the LZ)? 5 Enterprise Services a Services Add'nl Details Are there additional applications that are provided to the mobile edge? 6 Interoperability a "Back-end" Interop Can you reach other phones? b Dialing Plan Has one been developed for the capability? Summarize the dialing plan. c Security Interfaces Are mechanisms in place to dial to other levels of classification with this capability? 7 Legacy Integration a Summary What legacy communications can you “reach:” can you call STEs, DRSN, etc.? 8 Risk Management Framework
B-3
a Status of RMF Efforts Do you have an IATO, ATO etc.? b CSfC Solution Can you provide a list of selected hardware? Which components are not on the CSfC CCL? c Cyber Risk Does your implementation have a risk assessment from NSA? An ATO from the AO? d Known Security Concerns Summarize any known security concerns with regards to intercept or other cyber risks. 9 Supply Chain Risk Mgmt (SCRM) a Summary Summarize supply chain concerns (foreign tech that was integrated, etc.). 10 Phone-to-Phone a Existing Is there a capability to call from one phone to the other directly (no LZ)? (this is currently not supported by NSA) b Planned/Desired Is this planned or desired? 11 COTS Integration Describe your strategy to accomplish this COTS integration activity, any issues? D. Development Perspective 1 Lessons Learned a Summary Summarize lessons learned on the development process. 2 Implementation Evolution a Next Steps What are the next steps for this implementation? 3 Implementation Issues a Summary What ease-of-use issues were uncovered during initial fielding? b COTS Integration What (if any) COTS integration issues were experienced during development? c Product Availability What tech or commercial products are still required in the implementation? d Development Skills What development skills (IT skills) were contributors to the success of your project? e Issues with NSA CSfC What development issues (if any) related to the capability plans as written? E. Missing Questions Please add any recommended adds to the sheet.
B-4 Appendix C CSfC Compliance Crosswalk Tool
Motivation
The NSA capability packages describe the components required to implement a solution that is able to be accredited with nominal residual risk. Each component must be procured and integrated for the complete solution. Devices that have both been through NIAPP validation and have been registered for the CSfC program are added to the CSfC Components List (CCL) are specific to vendor, model number and version required (or later). Integrators often make choices that are not completely compliant with the guidance from NSA. A tool (excel and access database) was created to crosswalk the components on the CCL and the integrator’s selected components. This tool supports the accreditors and integrators.
Summary of Approach:
1) Import the entire NSA lists (these are regularly updated so the tool should be
maintained with the latest list). The list is available on the NSA site in table form
(Figure C-1 is a sample of a table from NSA).
C-1
Figure C- 1 Components List (Example) from NSA Site
(Retrieved 23 March 2017 - https://www.nsa.gov/resources/everyone/csfc/components-list/)
2) Structure the compliance package architecture (Figure C-2) within an excel
spreadsheet to identify required components (from the capability package). The
components were structured in a hierarchical way to aid comprehension.
Figure C- 2 MACP Configuration (from NSA) 3) Import the list of selected (by the integrator) components. Many will be similar to
the NSA list, but care must be taken to identify the model numbers and even the
particular configuration (this will take more research to develop a strategy for
C-2 tracking configurations of components). Often there will be issues with the
correct configuration that the integrator must deal with for a complete secure
solution.
4) Conduct a compare of the components with a lookup to see if the selected match
the approved components.
5) The compliance can be tracked using a color code (such as: Green compliant,
Yellow Component approved, but older version, Red not on the list all). These
are representative color codes for the prototype tool.
Figure C- 3 Screen Capture of Compliance Tool 6) Document why the non-compliant choices were made for the person working the
accreditation package.
7) Over time the change out of components could be made and the integrator can
track the number of devices that are still non-compliant – “yellows” and “reds”
C-3 that are still in the configuration and could be addressed in future system
upgrades.
The compliance tool was developed as a proof of concept. It could be maintained by the community, but the integrators would maintain the tracking of the configuration
over time (IAW RMF for managed risk over the life-cycle). The integrators need to be reminded that they are not constrained by the list, but can select components and then the user organization can accept the residual risk; the risks identified by the NSA on the classified document (refer to NSA web site for access to these documents) obtained from them plus the component differences identified through this compliance tool captures the complete range of risks to the implemented solution.
C-4 Appendix D Templates (Reference Architecture) for Final Architecture
Architecture artifacts span a wide range of topics (Table I) and should be tailored for the specific application. The architectural components provided by NSA as a foundation are available on line and are summarized as follows:
General Guidance Handout/Flyer FAQ (Technical and non-technical) Customer Handbook Various Informational Briefings Components CSfC Questionnaire (vendor completes) Capability Packages (and associated risk assessments – need to be requested – not on line)
Architecture Components and Related Artifacts (supporting artifacts)
Architecture Component Artifacts Enterprise Benefits • Benefits – Strategic Direction Enterprise Requirements/Policy • Policy Strategy • User Agreement User Experience • Use Cases • Service Level Agreements (SLAs) • User Requirements • Screen mockups Transport • Communications Systems Design (address cut-overs) Enterprise Services • Enterprise Service System Requirements (reference existing enterprise service docs) • Service Level Agreements (SLAs) Interoperability • Interoperability Integration with Legacy • Legacy Communications Plan Communications • Dialing Plans Risk Management Framework (RMF) • Risk Assessment (from NSA) – classified • Authority to Operate (ATO) Supply Chain Risk Management • Risk assessment (SCRM) Phone-to-Phone • Research strategy (future concepts)
D-1 D-2
D-3 All Viewpoint Project visions, goals, objectives, plans, activities, events, conditions, AV-1: Executive Summary measures, effects (outcomes), and produced objects. Solution architects will complete the AV-1 for their particular secure mobile application: Factors to Consider: 1. Architecture Description – include the team developing the architecture and contact information to include classified email address (and secure phone numbers). 2. Scope – this template (or reference architecture) includes the suggested views (and Viewpoints), but these may vary based on the specific solution being worked. Refer to notes on specific recommendations for views within this template set. 3. Purpose and Perspective – the solution architecture will support the development of the solution, maintenance of the capability, and accreditation activities – ID these uses and ensure sufficient detail is developed to support the RMF process at a minimum. 4. Context – consider the user of the system to anticipate the threat for intercepting communications. Consider the concurrent development of threat analysis by the intelligence community and couple this with the concurrent development of Government standards such as the MACP and view this as a changing environment that needs to be supported to ensure the latest security measures are constantly being integrated for the end-user. Finally industry products and capabilities are rapidly changing and these need to be leveraged. 5. Status – capture any issues with the development and current status. 6. Tools and File Formats – these can range from standard MS Products to sophisticated architect development tools. The tools use might be driven by availability of licenses and the existing skills of the architecture team 7. Assumptions and Constraints – always good for any activity, but with secure mobile keep in mind that there are external dependencies with the transport providers, commercial vendors and enterprise owners – capture the issues here. 8. Always keep in mind that this entire view serves as an executive summary and capture any issues to be worked early and consider publishing this view early to support stakeholder engagement. Note: Headings conform to the DODAF Standard (2017), http://dodcio.defense.gov/Library/DoD-Architecture-Framework/ All Viewpoint Definitions of all ontic terms used in an architectural description. AV-2: Glossary
Terms Definition
Secure Mobile Architecture Framework 1 D-4 Capability Viewpoint The overall vision for transformational endeavors, which provides a CV-1: Capability Effects strategic context for the capabilities described and a high-level scope. Attributes help define the solution Example Attributes Accessibility Flexibility Accuracy Foresight Affordability Interoperability (Net Ready) Agility Management and Control Availability Protection and Emissions Capacity Quality Attributes Coherence Security/Encryption Completeness Survivability/Restorability Coverage Technology Insertion Endurability Timeliness
Note: DOD JCAs (2017), http://www.dtic.mil/futurejointwarfare/cap_areas.htm Capability Viewpoint All the capabilities that are referenced throughout one or more CV-2: Capability Hierarchies architectural descriptions. (Hierarchy) Secure Mobile Access to: Services (Secure) Communication Services (see SvcV-1 Services) Voice (ID level of security – Secret, TS, etc) Video (VTC and streaming) Interoperability Requirements related to services (what other phones can be reached, etc) Data (email and information Services) Access at the Following Locations: … at what locations Office, Home, Auto, Air, CONUS and/or OCONUS, etc – should be defined Operating Locations End-user Device (EUD) Constraints: Ground Permanent (Office and Home) Form Factor - Phone, Tablet, PC, etc Ground Temporary (Travel & Temp Office) Features – battery life, one button dial, etc Ground Mobile (Ground, Maritime, Other) Airborne (Fixed and Rotary Wing Aircraft) Assumes an expectation of the latest technology … Cost Constraints … gives you these capabilities Capabilities Operate During Commercial Service Disruptions (assuming commercial is being used) – example Command, Control and Coordination during an earth quake the cell services is degraded, is the capability to continue operating a Situation Awareness requirement? [would require a priority service] Enterprise Communications (voice and email) Note: If capabilities are phased in, add a CV-3 Mission Support/Logistics Secure Mobile Architecture Framework 2 D-5 Data and Info Viewpoint Information needs. DIV-1:Conceptual Information Data and Info Viewpoint Data requirements. DIV-2: Data Requirements Model Data and Info Viewpoint The physical implementation of data elements. DIV-3: Data Implementation Data needs and views are required for mature mobile solutions only Enterprise Don’t consider email as data Data (it’s an enterprise service) Identify Mobile Data Needs and Enterprise Sources
Joint Information Environment (JIE) from DOD http://www.disa.mil/~/media/Files/DISA/About/JIE101_000.pdf Mobile Data Required (Examples) Enterprise Source Phone Directory Location on Enterprise Server – URL mail.smil.mil, etc Weather Data Weather Server …
Secure Mobile Architecture Framework 3 D-6 Operational Viewpoint The operational concept. OV-1: Operational Concept Extending Enterprise Services to the Mobile Edge Note: Priority access over cell not working yet Black (Encrypted) Transport Remember Transport impacts reliability and voice quality. Work to: Deny Threat Access
Operational Viewpoint Organizational context, roles, and other relationships among OV-4: Organizational Relationships organizations. MACP Roles/Stakeholders (augment with your organizations roles) National Security Agency (NSA)/Capability Package Authors CSfC Strategy Customer (for the MACP)/Capability Provider Developer Security Administer & Certificate Authority Administrator (CAA) Auditor Mobile Solution Integrator (if the customer does not integrate the solution) Transpor Enterprise Phone End User (of the mobile device) – ID all end users for the particular solution t Owner User Mobile Capability Transport Providers (Government and Commercial) ProviderIntegrator Classified Service Providers (Voice, Video and Data) Operational Viewpoint Rules that constrain operational activities. OV-6a: Operational Rules Operational Rules Potential Impact Mitigation Strategies Loss of Controlled Cryptographic Items (CCI) Investigation required and other actions … Employ CSfC “Security and Privacy Controls for Federal Ensure controls are implemented in the Robust cybersecurity program. (IAW RMF) Information Systems composed solution. and Organizations” Op. Rules Reduce Risk> Cross-check with system rules and staff draft rules to secure support early
Secure Mobile Architecture Framework 4 D-7 Project Viewpoint The dependency relationships between the organizations and projects and the organizational structures needed to manage a PV-1: Projects & Organizations portfolio of projects. Factors to Consider: 1. Integration with fixed existing infrastructure should be included (there are often issues with integration). 2. Integrate change agents into the effort to facilitate migration to the new tech./ease transition 3. Include life cycle funding and secure complete funding before starting effort
DODAF 2.02 Standard
Example
Project Viewpoint A schedule of activities and their resources with the key PV-2: Project Schedules milestones and dependencies. Factors to Consider: Involve Government, Integrators and entire team for effective project management 1. General Schedule Flow: Design System, Acquire Commercial Technology, Integrate, Initial Accreditation for testing, Test, Field and Accredit final system (sustainment planning is usually included, but full lifecycle sched. is not required) 2. Plan for schedule delays when integrating products that are less mature and need more integration time 3. RMF(Cyber Assurance) needs to be planned early to field capability in the shortest time (long pole) 4. Complete develop timelines may take one year to implement – be realistic with schedules 5. Consider phasing in capabilities over time – start with voice only, move to email etc., Secret and then TS, etc DODAF 2.02 Standard
Example Secure Mobile Architecture Framework 5 D-8 Services Viewpoint Services, service items, and their interconnections. SvcV-1 Services Services Viewpoint Relationships among or between systems and services in a given SvcV-3a Services & Systems architectural description. Transport Description Transport Description Enterprise (and Description Communications Commercial or Government Provide Communications Call/Gateway VOIP Calls Connect thru Landing Zone other enterprise) Services (Cellular, WIFI, SATCOM, etc Services Call Managers, Network Gateway Voice, Video and Standard Enterprise services to Priority Services Priority over commercial cell and WIFI (Government Services Info Services include applications classified at priority mechanisms should be integrated into the Security Services Termination of 2 layers of security (Secret, to TS and various levels service) (both must use AES256 encryption), Higher) Transport Security Security specific to the transport mechanism (example Security Appliances/Services – IDS, Security Services Standard IT Security IAW RMF for Services LTE encryption, WIFI WPA2, etc) With WIFI should deploy Firewalls, etc Fixed enterprise services WIDS. Security Services not just the minimum required by NSA! End-User Mobile Description Device End User Mobile Landing Zone Enterprise “Other” Enterprise Access to VOIP, VTC and Email Ap, Device Transport Voice Call Voice Enterprise Svcs Browser and other Aps Comms Access to Services/ Video Video Mobile Security Phone Hardened, Certificates, Enterprise Services 2 Security Layers Priority Gateway Info Info Security Security Security Security Security Don’t forget focus on end- user: Solution Boundary Remember Usability (“one-button” dial, biometrics?, phone directory services , DaR for improved email Services Viewpoint Measures of services for interesting periods of activity. SvcV-7 Service Measures Quality Measures Requirement “ilities” Requirement Voice Quality PESQ or MOS value of X. Video Quality EVQ, etc Reliability, etc 99.999 (five 9s) Availability Coverage Maps (TBD)
Services Viewpoint Emerging resources, standards, and skills that planners expect to be SvcV-9 Service Technologies & Skills available for future service development.
• Forecasting technology readiness against time. Service Trends • HR Trends Analysis. Mobile Access to Enterprise Improved APS • Recruitment Planning. Mobile Security Over-the-Air Provisioning, Hardening Tech, NFC Credentials Planning technology insertion. Priority Services Priority over commercial cell and WIFI • Landing Zone Security Improved Intrusion Detection System (IDS), Firewalls, etc • Input to options analysis External Info Services Voice – Cross Domain Solutions, VTC on the move (compression), info Services
Secure Mobile Architecture Framework 6 D-9 Standards Viewpoint Current standards constraining activities that produce solution StdV-1 Standards Profile resources.
MACP (NSA) https://www.nsa.gov/resources/everyone/csfc/capabilit y-packages/assets/files/mobile-access-cp.pdf
NSA Presentationhttps://www.acsac.org/2014/workshops/law/Watki on CSfC ns_NSA_CSfC_LAW2014.pdf Risk Management Framework (RMF) http://www.dtic.mil/whs/directives/corres/pdf/851001_2014.pdf Standards Commercial Solutions for Classified (CSfC) – Blueprints for composing solutions National Information Assurance Protection Profiles (NIAPP) – Secure Industry Components Risk Management Framework (RMF) – Cyber Security –accredit solution and look at impacts to existing ATOs – plan to work with the Authorizing officials early in the process (they may not be familiar with CSfC. Get with NSA if required. Policy (Wireless Intrusion Detection Systems, etc) Supply Chain Risk Management (SCRM), etc
Standards Viewpoint Future standards that will constrain activities that produce StdV-2 Standards Forecast solution resources. • StdV-2 Standards Forecast The description of emerging standards and potential impact on current solution elements, within a set of time frames. • Track Commercial and Government Standards Trends Standards Potential Impact Time Frames NSA Capability Packages Updates Changing requirements. Annual or greater updates. LTE Voice (VOLTE) May impact solution (or support new features). Two years out. … Secure Mobile Architecture Framework 7 D-10 Systems Viewpoint Systems, system parts, and their relationships. SV-1 Systems Composition and Interface Identification Red > Black Black > Red (and Grey) Red Red Key
End User Landing Zone @ Enterprise Other Org Organization Transport Service Provider (Red/Classified) (Red/Classified) Mobile Device (Cell/WIFI) System Entity Telephone LAN/WAN Info Aps Termination of Telephone VTC & System Encrypted Traffic VTC & Info Systems Element End-to-End WIFI Hotspot Security Info Systems (Optional) Security Appliances Red – Not Encrypted (caution threats can intercept) Black – Encrypted (safe to send over the air and public nets) Solution Boundary Grey – Partial (monitor for threats entering grey, catch them before they’re in the “red” nets) Systems Viewpoint Measures of a system. SV-7 Systems Measures Matrix System Measure Quantified RMF Documentation (IATT, ATO, etc) Complete Cybersecurity required documentation in hand for phase of development (acceptable shared risk between NSA and the AO) Note: most measures are associated with the services.
Systems Viewpoint Constraints on system activities. SV-10a System Rules Model
System Rules Mitigations/Impacts System can’t be operated without an accreditation. Start early on RMF or going operational may be delayed Accreditation must follow RMF Policy and Procedures Incorporate RMF activities in project plan For CSfC Applications RMF must address CSfC Rules and Procedures Closely follow the capability packages for implementations to include selection of CSfC review products (refer to NSA Site) Classified information must be protected IAW local policy and regulations Data at Rest Solutions can cause the device to not be classified when turned off else protect devices as classified would be protected. Operation of wireless tech in a secure space may be restricted by local policy Consider a “docking mechanism” for secure spaces, work to change Use of Commercial Technology may restrict options (End User License Restrict modification of commercial devices operating on nets to those modifications allowed Agreement or similar) by the cellular providers (cell phones may be restricted access to the net) Priority Mechanisms IAW Law (Support to Lawful Intercepts) Priority mechanism over commercial nets should be reviewed WRT legalities (ie National Security Emergency Preparedness Communications can be granted priority) Lawful intercepts Cross-check with operational rules and IAWstaff governing draft laws rules to secure support early Secure Mobile Architecture Framework 8 D-11