Www.cs.uccs.edu



TITLE \* MERGEFORMAT Hybrid Cloud Federated Identity Architecture Supporting Mission Critical First RespondersbyRandall E. GarciaM.S. ECE, Naval Postgraduate School, 1994B.S. EECS, University of California Berkeley, 1986A dissertation submitted to the Graduate Faculty of theUniversity of Colorado at Colorado Springsin partial fulfillment of therequirements for the degree ofDoctor of PhilosophyDepartment of Computer Science2018This dissertation forDoctor of Philosophy Degree byRandall E. Garciahas been approved for theDepartment of Computer SciencebyC. Edward Chow, ChairDr. Sang-Yoon ChangDr. Yanyan ZhuangDr. Richard WhiteDr. Edin MujkicDate: 4-17-18 Garcia, Randall E. (Ph.D. in Engineering) TITLE \* MERGEFORMAT Hybrid Cloud Federated Identity Architecture Supporting Mission Critical First RespondersDissertation directed by Professor C. Edward ChowAbstractDisaster response operations continue to suffer from poor information sharing across the responding organizations. This recurring trend results in degraded operations and potential loss of life and property. Emerging cloud computing solutions have the potential to help overcome information sharing obstacles. Cloud computing is a relatively new computing paradigm that provides increased flexibility and resiliency in information technology service delivery. This research proposes an architecture and policy approach to implement federated identity hybrid cloud solutions enabling first responders and disaster response. First responders continue to suffer the shortfall imposed by a lack of trusted and secure information sharing. The focus is on the security and implementation considerations for federating identity to enable rapid response. Here we propose a hybrid cloud architectural model and evaluation criteria for suitability, security and implementation policy.Keywords- Hybrid Cloud; Federated Identity; First Responders; Disaster Response; Cybersecurity; Public Policy.DedicationThis is dedicated entirely to my wonderful wife Jennifer.AcknowledgementsThe author acknowledges significant support from the UCCS and Microsoft teams for the technical and functional success of this work. Microsoft provided Azure Research Grant for Education for $5000 () during 2017-18 which provided the cloud computing environment to demonstrate the ideas herein. Gregg O’Brien tirelessly provided identity management input, Leo Wu and Ryan Zoeller assisted in PowerShell and Azure Quickstart deployment ideas, and Russell Anderson assisted with Azure instruction. Edin Mujkic validated the public policy components while Richard White provided expertise for disaster management practices and areas for improvement. A special thanks to Dr. C. Edward Chow for his help and guidance. From the first classes in 2002 for the SPACECOM-UCCS Graduate Information Assurance Certification to the final dissertation defense preparation, he has remained steadfast through mutual challenges for both of our families. And lastly, but most importantly, thank you to my gracious Savior Jesus Christ who has set my path before me and has given me the strength to finish the race. Table of Contents TOC \o "1-2" \h \z \u CHAPTER 1INTRODUCTION PAGEREF _Toc511050264 \h 11.1Overview PAGEREF _Toc511050265 \h 11.2Motivation PAGEREF _Toc511050266 \h 21.3Statement of the Problem PAGEREF _Toc511050267 \h 51.4Impact of Solution PAGEREF _Toc511050268 \h 51.5Research Methodology PAGEREF _Toc511050269 \h 71.6Contribution PAGEREF _Toc511050270 \h 81.7Dissertation Outline PAGEREF _Toc511050271 \h 92LITERATURE REVIEW PAGEREF _Toc511050272 \h 102.1Related Work PAGEREF _Toc511050273 \h 112.2Related Topics: Edge Computing PAGEREF _Toc511050274 \h 153Background: Mission Critical First Responders PAGEREF _Toc511050275 \h 283.1Scenario PAGEREF _Toc511050276 \h 283.2Domestic Response to Disasters and Events PAGEREF _Toc511050277 \h 283.3Information Security Requirements and Limitations PAGEREF _Toc511050278 \h 313.4Key Policies PAGEREF _Toc511050279 \h 313.5Key Processes and Products PAGEREF _Toc511050280 \h 333.6Key Technologies PAGEREF _Toc511050281 \h 363.7Challenges in Disaster Response PAGEREF _Toc511050282 \h 383.8Conclusion PAGEREF _Toc511050283 \h 404 HYBRID CLOUD COMPUTING PAGEREF _Toc511050284 \h 414.1Contribution PAGEREF _Toc511050285 \h 414.2Cloud Computing Model PAGEREF _Toc511050286 \h 414.3Public Sector Cloud Computing Adoption PAGEREF _Toc511050287 \h 434.4Cloud Cybersecurity Frameworks PAGEREF _Toc511050288 \h 444.5Preferred Cloud Approach PAGEREF _Toc511050289 \h 464.6Conclusion PAGEREF _Toc511050290 \h 475 Federated Identity PAGEREF _Toc511050291 \h 485.1Federated Identity Trajectories. PAGEREF _Toc511050292 \h 485.2Background PAGEREF _Toc511050293 \h 485.3Federated Identity Standards PAGEREF _Toc511050294 \h 565.4Federated Identity Cybersecurity PAGEREF _Toc511050295 \h 605.5Conclusion PAGEREF _Toc511050296 \h 616 Alignment of Hybrid Cloud Federated Identity Solutions PAGEREF _Toc511050297 \h 636.1Introduction PAGEREF _Toc511050298 \h 636.2Alignment of Community Cloud PAGEREF _Toc511050299 \h 636.3Alignment of Federated Identity PAGEREF _Toc511050300 \h 646.4Conclusion PAGEREF _Toc511050301 \h 647 Deploy a Hybrid Cloud Federated Identity Solution PAGEREF _Toc511050302 \h 657.1Introduction PAGEREF _Toc511050303 \h 657.2Solution Overview (Executive Summary) PAGEREF _Toc511050304 \h 657.3Recommendations PAGEREF _Toc511050305 \h 827.4Conclusion PAGEREF _Toc511050306 \h 838Conclusion and Future Research PAGEREF _Toc511050307 \h 848.1Known Concerns and Solutions PAGEREF _Toc511050308 \h 848.2Evaluation of Success Criteria PAGEREF _Toc511050309 \h 858.3Contributions PAGEREF _Toc511050310 \h 858.4Future Research PAGEREF _Toc511050311 \h 868.5Conclusion PAGEREF _Toc511050312 \h 88Bibliography90Appendices HYPERLINK \l "_Toc511050313" A. Federated Identity Hybrid Cloud Build Guide……………….100List of FiguresFIGURE TOC \h \z \c "Figure" 21 Cloud-based versus MCS based architecture for crowdsensing [57]. PAGEREF _Toc509161569 \h 2631 FEMA Mission Assignment Example3032 Demand for information communication technology services after the strike of disaster. [80]3941 Visual Depiction of the NIST Cloud Computing Definition [86] PAGEREF _Toc509161572 \h 4251 The Department of Defense CAC is used for Authentication, Authorization, and Access control. PAGEREF _Toc509161573 \h 5271 High level architecture for disaster response scenario. PAGEREF _Toc509161574 \h 6772 GOV initial in scope build to architecture (infrastructure and identity). PAGEREF _Toc509161575 \h 6973 GOV initial in scope build to architecture (infrastructure and identity). PAGEREF _Toc509161576 \h 7074 On-premises domain architecture, GOV domain (pre-federation) PAGEREF _Toc509161577 \h 7375 Community Cloud organizational set up (pre-federation) PAGEREF _Toc509161578 \h 7576 This solution mapped to the NIST cloud model. [86] PAGEREF _Toc509161579 \h 7777 Standards-based architecture for federation (SAML 2.0, OAuth). [132] PAGEREF _Toc509161580 \h 79CHAPTER 1 IntroductionOverviewDisaster response is a crucial public and private sector process which aims at minimizing loss of life and damage and maximizing relief impact. The end state of these operations is to restore critical services and enable governments, businesses, and individuals to return to steady state functions and normal operations CITATION Fed13 \l 1033 [1]. Successful disaster response maximizes the relief impact and restores essential functions and services of government within an ideal timeframe. The early stages of disaster response often determine the success or failure of the overall effort. A key shortfall is secure and rapid information sharing (e.g., interoperability) across organizations CITATION Des11 \l 1033 [2].Cloud computing CITATION Mel11 \l 1033 [3] offers the promise of elasticity or rapid provisioning of information technology services as demand fluctuates, often due to the rapid scaling (and retrograde) of response activities. The on demand, self-service nature of cloud computing allows deliberate and ad hoc service instantiation. Disaster response can be deliberate, ad hoc, or both. Broad network access allows connectivity from thick, infrastructure-rich devices as well as mobile devices. Responders require access from a variety of platforms. The cloud service models provide flexibility and security in service delivery options.Identity CITATION Tho11 \l 1033 [4] becomes foundational to trusted information sharing. Government and private organizations hesitate to collaborate with participants lacking validated credentials. “Verifiable trust CITATION Sta11 \l 1033 [5], CITATION Mey131 \l 1033 [6]” is an elusive entity, and its establishment, or lack thereof, causes delays in disaster response. Historically, responding organizations participate in disaster events via siloed identity, processes, and information technology (IT) solutions which limit cross-organizational trust or integration. Federated identity standards continue to evolve and provide balance between competing demands of cybersecurity and information sharing. This research follows the original scope outlined in CITATION Placeholder1 \l 1033 [7]. The introduction section captures the frame of reference to understand disaster response characteristics and the role of identity. Architecture and threat sections highlight the proposed solutions and the associated risks. The related work sections provide a survey of solutions and investigation into the use of federated identity in hybrid cloud computing environments to support first responders. The cybersecurity considerations highlight issues related specifically to cloud and federated identity. Detailed proposed tasks are in proposed dissertation tasks followed by compelling future work which would leverage this proposed solution. Outcomes of the research include the proposed architecture and policy changes to implement solutions supporting the scenario. MotivationIn each disaster response, ideas related to using emerging technology abound, yet policy decisions and lack of consensus impede progress. From CITATION Placeholder1 \l 1033 [7], cloud computing continues to generate significant discussion and hopeful dialog in both public and private sector. In the same discussion, there are varied opinions and misconceptions about what secure cloud computing provides. There are no solutions which allow responders to rapidly authenticate identity and immediately begin collaborating on a common platform. Past examples for provisioning identity solutions for response scenarios have met various levels of success. The authors in CITATION God05 \l 1033 [8] provide a robust and secure solution for information sharing that uses role-based access control and attribute certificates. Their approach includes the provisioning of root certification authorities, certificates, server, and client configuration (adding root certificates). All users fall under a single structure. Hoffman et al. CITATION Hof09 \l 1033 [9] propose a context aware approach to support first responders with robust and adaptable information management and decision support. Landahl CITATION Lan06 \l 1033 [10] highlights the complexity of the current distributed identity model and proposes a universal token-based identity management schema for terrorism events. Again, this is established under a single identity authority source. Bertino et al. CITATION EBe09 \l 1033 [11] establish high level identity verification policies applying identity attributes, zero-knowledge proof protocols, and semantic matching. Schwartz and Ferrell find continued interoperability issues between the US government and civilian relief organizations CITATION Sch07 \l 1033 [12] in disaster response collaboration.Another motivation is that a secure cloud computing environment depends on several security solutions working harmoniously together CITATION Jan11 \l 1033 [13]. From a security perspective, the public sector faces one of the greatest challenges in adopting cloud computing. Very little guidance exists to provide the details required to make an informed “leap” to cloud computing models. Guidance to this audience typically includes no more detail than cautions to ensure the cloud provider has the requisite security controls in place CITATION Kun11 \l 1033 [14]. To date, the Federal Risk and Authorization Management Program (FedRAMP) CITATION FED16 \l 1033 [15] process has certified multiple companies as authorized cloud providers. Example services include two IaaS offerings from Amazon (AWS and AWS GovCloud), IaaS and PaaS from Microsoft (Azure public cloud solution), and PaaS from Oracle. For this reason, we wish to assess the identity management features for use of such platforms. Additionally, other SaaS solutions are in place for the government such as the delivery of office automation and collaboration (Microsoft O365) and workflow (Ains eCase workflow and Freedom of Information Act processing). The California Department of Justice codified an agreement with Microsoft for its Government Community Cloud offering CITATION Dep13 \l 1033 [16], and that agreement resulted in transition of services for the City and County of San Francisco CITATION Sle14 \l 1033 [17].While use of these solutions should increase as they are proven, there is currently little guidance on how to implement identity solutions in a hybrid computing environment. Public sector organizations maintain their legacy datacenter environment while attempting to transition to a state that balances the cloud component in a way that benefits them and maintaining the tenets of security.From a more personal motivation, the author participated in the 2004-2005 Indonesia Tsunami Relief as part of Combined Support Force-536. This unprecedented disaster response resulted in 280,000 lost lives and billions in damaged infrastructure. Lack of expedient information sharing across this “come as you are” response resulted in initial confusion, uncertainty, and inefficient relief operations. Fast forward to other events (Hurricane Katrina, Haiti Earthquake, the Great East Japanese Earthquake and Tsunami, Hurricanes Sandy and Irma, California and Colorado Wildfires, and others), the identical issue of poor information sharing at the start of the response resulted in delayed or degraded actions. In essence, the same trend across all events had the same negative impact.The University of Colorado at Colorado Springs and the Federal Government have solid partnerships related to homeland security. In 2002-2003, the author and advisor participated in the initial USSPACECOM-UCCS partnership in a National Security Information Assurance Certification Program. Colorado Springs is an emerging center of excellence for homeland defense, cybersecurity, and disaster response, home to US Northern Command (NORTHCOM), and has vast amount of activities related to partnerships in maturing related fields of study. In June of 2013, the author was impacted in the Black Forest Wildfire north of Colorado Springs, Colorado. As a victim versus a first responder, a new aspect of the impact of disaster response information sharing became apparent. Additionally, the author realized a convergence of emerging technologies, standards, and policies which could potentially bring “the perfect storm” of enhanced information sharing solutions. Important to the solution for both the responder and those supported is the security of such a resolution, and the intent is to “bake in” the tenets of cybersecurity-confidentiality, integrity, and availability. This work represents those ideas. Statement of the ProblemFirst responders require rapid information sharing solutions for disaster response which support verifiable identity, authentication, simplicity, scalability, and resilience. Underlying the solution is an ability for responders to “come-as-you-are” for little to no-notice events. Impact of SolutionThe solution proposed answers a key question in national security and disaster response operations: “how can we make disaster response information sharing more effective and more secure?” Hybrid cloud federated identity changes today’s paradigm of slow, ineffective information sharing and initial confusion to one of rapid “plug and play” for all responding organizations, but in a more secure manner. We take a process of 7-10 days today to a process which takes 30 minutes to establish and an order of seconds to connect and share within the disaster response network. This is all done with a responder’s day-to-day identity and credentials, thus leaving no need for new accounts and passwords to memorize.From a knowledge management perspective, this solution addresses the points:What do I know and with whom do I need to share?What do others know about a topic on which I need more information?How can distributed collaboration enhance effective decision making?The confusion with no-notice disaster response will be minimized, as will the time to establish secure collaboration. This has the impact of accelerating disaster response efforts, saving lives, mitigating human suffering, and speeding a return to normal operations. The hope is that by addressing technical, cybersecurity, and policy issues, the work presented here can be rapidly incorporated by the disaster response community to drive effectiveness for the next event. This is a very real proposition given our reliance on technical standards, government-approved certification methods, and straightforward process definition. Specifically, we prove here that organizations such as FEMA and Red Cross can implement these changes today with only minor policy and technical changes.Research MethodologyOur approach was to align an identity management architecture across a hybrid cloud model which would enable “no-notice,” come-as-you-are participants in a disaster response. The three overarching tasks included the following.Develop the ArchitectureGiven the finding in our literature study that no similar architectural idea existed for this scenario, our first step is to develop the architecture on paper. This includes capturing use cases, proposing a scenario, developing the communication node representation of the architecture, capture notional organizations responding and induvial participants. The initial threat model is to be captured as well as the in and out of scope components and factors as we move to the build phase.Develop Federated Identity SolutionsThe next architectural “overlay” is that of the identity management and federation services. We leverage principles and standards and refine which fits the refined scenario. We build the home datacenter solutions for each organization, reflecting what is typically in place today as the “private cloud.” Additionally, we establish the disaster site where all will virtually meet to execute the response. We then federate the identities to enable rapid connectivity and information sharing. Key is to document the processes which organizations will have to follow for this to work. Lastly we will refine a threat model and assess the solution’s suitability against our original goals CITATION Placeholder1 \l 1033 [7], CITATION Gar17 \l 1033 [18].Build and Assess SolutionWith most of the work complete, we finish and document the build, capture performance, document the final architecture, capture the processes needed to connect, refine the threat model, and assess suitability. The results include work products such as the architecture, federation practices, assessment, and recommendations. ContributionThe primary contribution is the first hybrid cloud federated identity solution which accelerates the disaster response information sharing capability of disparate responders. The “come as you are” constraint is met, and simplicity and mission success are the perceived outcomes. Key contributions include:Research linking disaster response and cloud computingWe demonstrate that emerging cloud solutions enhance disaster response effectiveness. Research linking disaster response and federated identityWe reveal how foundational verifiable identity and a federation approach enhance response success and trust. Establish federated identity hybrid cloud architectureHere we “stretch” the identity architecture across the private and community (hybrid) cloud construct to enhance “ability to connect” quickly.Capture processes to connect in a “come as you are” approachWe provide policy change to make the solution successful vis-à-vis providing the “how to connect” approach for each organization.Address process and policy issues for successful deploymentWe highlight first federated identity hybrid cloud policy which will augment or replace legacy policy. Dissertation OutlineFollowing this overview chapter, Chapter 2 is a literature review of the areas of federated identity, hybrid cloud models and their emerging relevance to solving today’s problems as it relates to disaster response. Chapter 3 characterizes the organizations, processes, policies, and tools for effective disaster response conduct. Chapter 4 delves into hybrid cloud computing, and why this emerging paradigm was chosen for this problem. Chapter 5 includes a discussion on aspects of identity and focuses on the federated identity process as it applies to our use case. We perform an alignment of hybrid cloud and federated identity relevant to this scenario in Chapter 6. Chapter 7 we build, deploy, and evaluate the solution in an actual cloud lab, testing the architecture against criteria in CITATION Placeholder1 \l 1033 [7], CITATION Gar17 \l 1033 [18] and CITATION Gar13 \l 1033 [19]. This gives us the opportunity to emulate a short-notice disaster response scenario with participating organizations who have never personally interacted prior. Chapter 8 provides conclusions and areas for future research. Chapter 2Literature ReviewFirst responder ability to effectively respond to incidents has improved somewhat in the past two decades CITATION Sta14 \l 1033 [20]. Responders across the spectrum anticipate disasters and are prepared, via exercises, training, and feedback, to deliberately respond to events. As an example, every wildfire season (spring to summer to early fall), there are activities across the US at the federal CITATION USN17 \l 1033 [21], state, and local levels which “lean into” the executing of wildfire response. Disaster responders understand the workflow, templates, information exchange, command and control, and activities of disaster response. While this is the case, no two events are ever the same, and the participants are always made up of those organizations and individuals available at that given time. No technical or procedural solution brings these disparate groups together from a single event-focused approach. The responders arrive, rely on their “parent” or “home” solutions and accounts, and once they start working, are reticent to new injections of technology or processes during the event. These get codified, for better or worse in the first hours or days of work. As indicated in multiple references CITATION Placeholder1 \l 1033 [7] CITATION Gar17 \l 1033 [18] CITATION Col05 \l 1033 [22] CITATION Sta14 \l 1033 [20], disaster response is “come as you are” activity. Related WorkResearch related to all three components: federated identity, hybrid cloud, and a first responder audience, is rare. While many theoretical solutions exist, there are few practical models to leverage against the desired scenario. Yan et al. CITATION Placeholder2 \l 1033 [23] propose federated identity with hierarchical identity-based cryptography for mutual authentication and key distribution. They capture security and privacy as key issues in cloud computing and promote a solution which simplifies key distribution and mutual authentication in a hybrid cloud model. Their identity-based cryptologic solution is in opposition to de facto public sector approaches and is therefore untenable. The highly-centralized approach also does not expedite resiliency in a disaster scenario. Another hybrid cloud federation scenario proposed by B. Prasanalakshmi and A. Kannammal CITATION Pra12 \l 1033 [24] promotes a promising approach. Theirs is a hybrid cloud internal/external single sign on (SSO) via Security Assertion Markup Language (SAML). This helps with the private-public cloud interface in our scenario. They employ federated identity management multifactor authentication including biometrics. A key factor is it leverages the prevalence of SAML as a federation standard, thus encouraging wide adoption. A detractor is that it relies on multimodal biometric catalog of users a priori (not at all practical in a disaster response), and the primary application is secure hybrid cloud infrastructure federation vice an enabler to the mobile end user community.From and identity management perspective, Celesti CITATION Cel10 \l 1033 [25] proposes a distributed cloud information sharing framework with federated identity as a foundation. The research introduces concepts in cloud computing and security, focusing on heterogeneous and federated scenarios. It is an innovative approach which establishes, essentially, “cloud federation.” The approach, however, employs “home cloud” and “foreign cloud” concepts counter to standard cloud frameworks. They propose a somewhat cursory architectural discussion with no implementation results. Practically, it requires broad trust agreements which may not be practical, and proposes third party identity management IdM not palatable to public sector.With trust at the center of their research, CITATION Kha10 \l 1033 [26] Khan and Malluhi discuss trust issues and technologies to solve cloud computing security concerns. They capture policy and human factors which currently preclude trusted information sharing environments. Short of practical solutions, theirs is a research survey or “catalog” of issues and approaches. Sengupta CITATION Sen11 \l 1033 [27] et al. provide a framework and methodology for assessing cloud security issues which help organizations adopt cloud computing. The research sets conditions of success and roadmap for most cloud security considerations to include identity and access control. While their approach provides a framework but no specific solutions, the researchers plan to develop detailed framework and tools to aid migration to the cloud. Any drive toward cloud adoption, with security in mind, promote progress in the area.Given the prevalence of federal government in large-scale responses, Chuan-Hao’s research CITATION Chu09 \l 1033 [28] provides a promising perspective of a national authentication framework. It details and compares various token types and identity frameworks (PKI, SAML, WS-F, OpenID, and Infocard) and recommends best combination of technologies, protocols, and standards. From our problem set, it is less focused on cloud solution sets and, instead, presses authentication standards versus federation of identity. From this perspective, it would be useful for the “front end” authentication component of the problem, but not as relevant to the partnering that results from a federated solution.Dourandish et al. CITATION Dou06 \l 1033 [29] employ a services-oriented architecture to map local data formats and the terminology of the community of practice managers to domain ontologies that are shared by all the participants in the greater information-sharing system. This enables a role-based access control mechanism which, in this case, allows military to civilian communication.Zissis and Lekkas CITATION Zis12 \l 1033 [30] propose a Trusted Third Party which assures specific security characteristics in a cloud environment. Their research begins with an identification of cloud security requirements, proposes PKI solution which interfaces with SSO and LDAP, and applies standard systems engineering processes to the cloud security conundrum. In a government environment, however, the Trusted Third Party concept not palatable to Government Cloud, and it adds a layer of third party PKI to an already complex architecture.Another approach proposed by Dreo CITATION Dre13 \l 1033 [31] et al. proposes a cloud of clouds model to federated identity. The scenario includes a “disastrous event” wherein the Identity Provider (IDP) to Service Provider (SP) relationship scales from a 1:1 to a m:n factor. The paper addresses access, incident management, and security reporting with the objective of developing technical and organizational solutions to ensure secure federated inter-cloud identity management. The greatest challenges the research faces are proprietary inter-cloud key management and identity data exchange protocols which would require adoption by public and private sector alike.Related to wildfire response and command and control information systems, Zambrano et al. CITATION Zam17 \l 1033 [32] address the challenges of distributed collaboration and capture an architecture for command and control (C2) which assists with:?shared situational awareness?internal and external communication/collaboration?effective decision making?distributed communication of key decisionsTheir resulting, “tactical” solution provides distributed communication across multiple fire brigades, and successful C2 over the movement, assignments, and actions of those distributed units in a bandwidth-constrained environment.Wozniak, Rossberg, and Schaefer CITATION Woz13 \l 1033 [33] propose a novel means to validate information collected as part of disaster management and perform a simulation study to validate their results. Social media explosion provides the potential to gather a larger scale of input for disaster management than ever before, however as discovered in CITATION Placeholder1 \l 1033 [7], bad actors also find means to cloud the information and use disinformation to interrupt the disaster response. Their goal is to obtain trustworthy information, and the authors use a witness-based report verification to validate source information in disaster management. Using a rating approach which relies on the population, they introduce Voting for Urgent Events (VUE) as a distributed, social mechanism to verify activity. The verifier nodes confirm initial or recurring reports, and the weight of the validation contributes to the allocation of scarce resources in disaster response. They admittedly take their approach from the success of social swarming applications popular in social networking.Clearly a risk of such an approach is the privacy and security of participants. Their design architecture, very deliberate in its approach, includes functional, security, and privacy objectives as core measures of effectiveness. The four phases of the VUE approach include:Token negotiation: Negotiation of group key exchange using the Group Diffie-Hellman with an output of negotiated key pairs.Event reporting: Employing TLS and leveraging validation using the key pairs, mobile subscribers identify events of interest. Duplicate reports are deconflicted to provide foundational event data. Confirmation requests: Based on geolocation and authentication, the requests proceed to query for event corroboration and confirmation.Witness feedback: Using a voting approach (hence “VUE”), the authenticated witnesses validate events within the time limit established by the verifier. Their practical results reveal an increase in validity of reports, a decrease (over time) of malicious users (marginalized via mass reporting), and an increase in the effectiveness of disaster response information validation.Amid the above research, no solution provides the ability to address the “come as you are” nature of disaster response, rapidly connect disparate users, and scale quickly to accommodate the flow of responders and logistics. Related Topics: Edge ComputingAn emerging field that is very relevant to the three areas of hybrid cloud, federated identity, and first responders is edge computing. Given communication challenges at the seams between responders, the communications infrastructure, IoT devices, and the cloud, edge computing has a potential to add significant value to real-world solutions. Edge computing refers to the enabling technologies which allow computation to be performed at the edge of the network. CITATION Shi16 \l 1033 [34]. The “edge” is any computing or network resource along the route between data sources and data centers / cloud locations. The very characteristic of disaster response (connection-challenged, chaotic, ad hoc, austere) provide viable cases whereby the benefits of computing at the edge show promise of enhancing disaster response effectiveness. A few examples of edge in our scenario could include:A mobile device for a first responder is at the edge of the responder and the access point.Mobile command centers are at the edge of the response and the cloud connection.An intermediate distribution point is at the edge between the internet and the regional disaster scenario.Nader Mir and Salvatore Loreto capture recent initiatives in “Cloud and Edge Computing” CITATION Nad17 \l 1033 [35] and highlight paradigms of virtualization architectures and geography-based architectures for deploying clouds. They address recent attention on datacenter network architectures, security, privacy, and increased demand for standardization for multiple aspects of edge and cloud computing. In response, Mittal et al. CITATION Mit17 \l 1033 [36] capture an approach to integrate edge computing with cloud computing. Their primary findings related to how edge computing complements our current cloud model and provides new solutions where none previously existed. As noted by Mouradian et al., CITATION Mou17 \l 1033 [37] the distance between the cloud and the end devices might be an issue (and application) for latency sensitive applications such as disaster management. In “Bringing Cloud to the Edge,” H. Chang et al. CITATION Cha14 \l 1033 [38] introduce a new model which addresses the cloud/edge seam, appropriately named “Edge Cloud.” As could be anticipated, the approach augments the private cloud/data center model with edge service nodes which compensate for issues with computation/storage/processing locally. In addition to this contribution, they create an OpenStack cloud solution for enabling latency-compensating indoor localization and bandwidth-saving video monitoring. Chandykunju Alex and Aditya Vijaychandra CITATION Ale16 \l 1033 [39] leverage the emergence of drone technologies and robotics to address edge computing at the seam of the disaster response. Theirs is an objective to expedite search and rescue (SAR) in inaccessible locations. As lines of access and mapping inconsistencies post-impact challenge SAR teams, the authors’ approach is to generate primarily GIS and mapping knowledge closer to the activity as the devices and associated network overcome the challenges of limited range and sparse infrastructure while balancing the link budget against power consumption. The result is to generate a local-remapping and sensing of the impacted area which contrasts with the pre-disaster layout. Their additional heat-sensing drones, part of the architecture, also assist in mapping and locating distressed persons as part of the relief effort. A. Goel et al. CITATION Goe15 \l 1033 [40] provide an approach to mitigate privacy and security issues in hybrid cloud edge computing while enhancing the federation of identity to simplify authentication and access control. In their work, they reveal how federated IdM and hierarchical identity-based encryption allow inter-server communication to speed authentication (almost in a “cloud-of-cloud” approach much like CITATION Dre13 \l 1033 [31].) This accelerates access at this seam and facilitates spread of trusted identity, primarily between servers and authentication mechanisms. Also emphasizing data privacy in a hybrid cloud environment, N. Abwnawar et al. CITATION Nas17 \l 1033 [41] leverage the SANTA policy language to add an access control / privacy component. Their approach includes mobile and hybrid clouds, and they capture privacy concerns relevant to our disaster response scenario. Given the amount of data transferred between mobile and edge devices as well as cloud systems, the securing of data becomes a concern. SANTA is an existing language for capturing access policies in computing systems. While not a perfect match to the scenario, the authors saw this access control language as a promising option for capturing and implementing privacy measures. Given a mobile cloud computing scenario which includes devices, edge computing, and cloud, they conceptually refine access policies to data location, both physically and logically. Using location as a factor, they propose a more granular approach to establishing privacy in the edge construct. S. Shirazi et al. CITATION Shi17 \l 1033 [42] emphasize the impact of operations on the extended cloud (edge and fog) on security and resilience. Leveraging knowledge of existing architectural implementations, theirs is a “security” lens which, as they examine, includes the addition of anomaly-detection and policy-based approaches. In their background material, they provide an excellent comparison of features in both the cloud and edge paradigms (useful for other research). In addition to rendering issues and approaches to security and resilience, the authors provide an essential, comprehensive review and history of cloud, edge, and fog computing. Smart cities initiatives play a practical role in disaster response as well as edge computing. In CITATION Cha17 \l 1033 [43], Perera et al. provide a survey of smart city fog and edge computing initiatives and trends. One issue from the IoT overabundance is the volume of waste with unprocessed and unfiltered information being targeted for cloud storage. They argue that the edge could have increased knowledge processing which would alleviate the wastage and focus effective use of content. In a volume of researching recent ideas, they identify ten key characteristics of fog computing, and identity the functionality required of fog computing platforms. (Here fog is used interchangeably with edge). Unlike other attempts to develop edge / fog characteristics from security or networking perspectives, theirs is wholly from a platform development and end user perspective. The contribution to our study is one of discovery and availability of edge computing resources within the smart cities initiatives and application to disaster response and recovery. Also approaching issues from the smart cities trend is W. Hou et al. CITATION Hou18 \l 1033 [44] They propose efficient means to address bandwidth saturation at the edge/backhaul interface through virtual network embedding (VNE). This supports collaborative edge computing by maturing the network as edge devices fail. Mathematically they trace their architecture design and practical scenarios to ensure efficiency and resilience. The “green” survivability is a minimization of edge device and network transmitting power and minimization of backup resources required. Related to this edge performance and optimization, J. Skirelis and D. Navakauskas CITATION Ski17 \l 1033 [45] perform multiple experiments to assess which variables impact performance the most. With an emphasis on the impact of bandwidth consumption and delay, they find that IoT edge performance factors are heavily influenced by the network topology. Deploying the EdgeNetworkCloudSim software package, their results confirm these initial findings but leave more issues uncovered than solved. Q. Zhang et al. CITATION Zha18 \l 1033 [46], recognizing the value of video-generating IoT devices in a disaster scenario, fuse data from the edge stakeholders into a virtual “shared data set” for consumption. Their solution interfaces with the Firework data processing platform to reduce latency and decrease network impact. Their result is an extensible hybrid cloud and edge computing application which enhances shared situational awareness. The design takes privacy into consideration and enables a “subscriber” approach to local data and services. Via a practical experiment consisting of mobile device and traffic cameras at the edge, they demonstrate the goals (related to latency and network) and provide others with their architectural framework. The framework enables deployment of other IoT edge applications. Also related to performance, T. Zhao et al. CITATION Zha17 \l 1033 [47] take a scheduling and maximization approach to increasing the probability of meeting delay requirements of services in the edge/cloud interface. The algorithm of scheduling proposed provides not only a model for future work but insight into characterization of edge service modeling. They also provide an approach to allocate computational resources to edge cloud users. As expected, their findings are that more resources should be applied to tasks with stringent delay bounds and less to those with loose delay bounds. Leveraging human knowledge of disaster response and the mobile cloud, L. Guerdan et al. CITATION Gue17 \l 1033 [48] propose a means to efficiently and intelligently allocate disaster response resources. Their framework, Augmented Resource Allocation (ARA), is tested via a simulation to determine streamlining of information flow for disaster response. The key components include human knowledge (specific to the disaster situation), dynamic edge routing algorithms, and centralized information storage and retrieval (more cloud-like in approach). The goal is enhanced decision making of incident commanders. Through a construct of three planes – the data plane, the control plane, and the human plane – they determine effectiveness of augmenting network and data flow decisions with knowledge interfaces. Their practical example is one of optimal dispatching of emergency response resources (e.g., medical triage) using the ARA model. The quality output in each case increases with corresponding human pairing with the infrastructure algorithm allocation. J. Zhang et al. CITATION Zha171 \l 1033 [49] develop an approach to optimize mobile terminal energy consumption, time delay, and monetary cost via a cloud and wireless resource allocation algorithm. Using a game model (Joint Resource Allocation – Evolutionary Game (JRA-EG)), they find interrelated impact on each of the three variables from mutual effect. The result is an effective algorithm tested against previous results, providing designers insight into behavior of edge networks within constraints discussed. Similarly, balancing guaranteed quality of service (QoS) with minimum system cost, X. Ma et al. CITATION MaX17 \l 1033 [50] apply a decision model to assess mobile request directing to edge versus cloud. Their approach, named Cloud Assisted Mobile Edge (CAME) computing accepts mobile requests and applies optimal resource provisioning to dynamically tune traffic shaping depending on resource efficiency. They find that their approach optimizes traffic over previous “local-first” and “cloud-first” algorithms. K. Kaur et al. CITATION Kau18 \l 1033 [51] likewise contrast optimization objectives at the edge for energy and latency and energy and bandwidth. Their finding is that edge computing models to date have taxed local bandwidth to an extent that frustrates user objectives. They propose a software-defined network edge-cloud interplay for streaming big data in an IoT environment. Their flow scheduling scheme produces efficiency optimized to counter the bandwidth constraint challenge. T. Subramanya et al. CITATION Sub17 \l 1033 [52] address a practical architecture focused on mobile edge computing. Given the prevalence of LTE networks at the edge, the authors use software defined network and cloud computing principles to create a mobile edge computing (MEC) architecture for those networks. The architecture includes three components of the MEC Radio Access Network (RAN) Information Interface (MRI), MEC application platform services, and MEC applications. They explore the use of video content caching locally employing this architecture, and successfully rerouting such traffic to the local MEC applications. With the emergence of 5G, solutions at the edge will enhance mobile responders throughout all phases of operations. Related to research maturity, Avner Peleg captures some of the confusion CITATION Pel17 \l 1033 [53] with topics related to cloud, fog, edge, and other recently-evolving terms. Fortunately, organizations such as NIST have stepped into to codify standards and terms of reference to enhance mutual understanding. From an optimization of edge resources perspective, Arnd Schirrmann CITATION Sch17 \l 1033 [54] assesses, via simulation, the technical and cost aspects of resources in a use case of airborne services in disaster response. The simulation includes airborne surveillance (for situational awareness) and communications services. He develops a link and time-based budget based on assessment of use in different disaster scenarios. The outcome is an approach for optimizing edge resources from a performance and cost perspective. Also related to edge optimization, G. Premsankar et al. CITATION Pre18 \l 1033 [55] validate the demand for edge computing for optimization of bandwidth and processing in a 3D application sharing scenario. They confirm the network bandwidth and communication latency bottlenecks, and provide a use case representing enhancements to virtual and augmented reality applications. Helpful to the problem definition, the find current edge or fog definitions lacking and that the “edge of the network” is not clearly defined. To address this, they characterize a threefold taxonomy of edge computing platforms: resource-rich servers deployed at the edge, heterogeneous edge nodes, and edge-cloud federation. They highlight that the IoT is characterized by devices which are resource-constrained, to include sensors, smartphones, wearables, and others. Via a use case of mobile gaming, they test issues related to response delay, bandwidth overload, and the actual usability of the system (at a given point of saturation, the gaming system risks becoming unresponsive). As augmented reality becomes a real-world solution for disaster response, this use case is relevant. As expected, their comparison between traditional regional data center approaches versus edge computing reveals a very real need for edge solutions and maturity. K. Wang et al. CITATION Wan18 \l 1033 [56] also face similar difficulties with the use case of mobile vehicular networks at the edge. Alluding to IoV or “internet of vehicles,” they propose a collaboration vehicular edge computing framework called collaborative vehicular edge computing or CVEC. They provide a robust comparison of the areas of MEC, fog computing, cloudlets, and cloud computing, and ensure that their solution maps to this framework. The CVEC framework enables organization of available vehicle network resources to provide enhanced vehicular services (sample applications being vehicle safety and vehicle efficiency). In addition, they apply software-defined edge computing to enable both horizontal (inter-vehicular) and vertical (device-to-cloud path) collaboration. Lastly, they pursue application to software defined networking, network function virtualization, and blockchain. The Social networking and crowd interface are fascinating components of the edge model. Contribution from individual contributors has been shown to both help and detract from disaster response missions. Wozniak, Rossberg, and Schaefer CITATION Woz13 \l 1033 [33] propose a novel means to validate information collected as part of disaster management and perform a simulation study to codify their results. They address deployment considerations and the need for standardization, but the clarity and architecture they provide are significant contributions.Social media explosion provides the potential to gather a larger scale of input for disaster management than ever before, however as discovered in CITATION Placeholder1 \l 1033 [7], bad actors also find means to “cloud” the information and use disinformation to interrupt the disaster response. The goal is to obtain trustworthy information, and the authors use a witness-based report verification to validate source information in disaster management. Using a rating approach which relies on the population, they introduce Voting for Urgent Events (VUE) as a distributed, social mechanism to verify activity. The verifier nodes confirm initial or recurring reports, and the weight of the validation contributes to the allocation of scarce resources in disaster response. They admittedly take their approach from the success of social swarming applications popular in social networking. Clearly a risk of such an approach is the privacy and security of participants. Their design architecture, very deliberate in its approach, includes functional, security, and privacy objectives as core measures of effectiveness. The four phases of the VUE approach include:Token negotiation: Negotiation of group key exchange using the Group Diffie-Hellman with an output of negotiated key pairs.Event reporting: Employing TLS and leveraging validation using the key pairs, mobile subscribers identify events of interest. Duplicate reports are deconflicted to provide foundational event data. Confirmation requests: Based on geolocation and authentication, the requests proceed to query for event corroboration and confirmation.Witness feedback: Using a voting approach (hence “VUE”), the authenticated witnesses validate events within the time limit established by the verifier. Their practical results reveal an increase in validity of reports, a decrease (over time) of malicious users (marginalized via mass reporting), and an increase in the effectiveness of disaster response information validation.Related to the social networking plane is the concept of “crowdsensing.” Martina Marjanovic et al. CITATION Mar18 \l 1033 [57] propose an edge computing architecture for mobile crowdsensing, a human-driven IoT approach to observer societal behavior. Disaster responders leverage such input to characterize the population and to minimize the “noise” of social media reporting. Massive social reporting in the traditional sense employs a highly centralized cloud model in which data networking extends from the edge to the providers (Twitter, Facebook, Google Maps, etc.) They compartmentalize this centralized model and propose a decentralized MEC architecture with infrastructure capable of data processing and aggregation closer to the data sources (as represented in the below figure). Figure 2 SEQ Figure \* ARABIC \s 1 1 Cloud-based versus MCS based architecture for crowdsensing CITATION Mar18 \l 1033 [57].They recognize the overhead created by this local architecture and perform assessments using data sets from actual users in South Korea. Interestingly they find that a small amount of MCS services deployed at the edge, with a relatively short installation time, provides significant benefits to relieving the cloud networking burden and increasing local situational awareness. Moghaddam et al. CITATION Mog18 \l 1033 [58] provide a related edge component from a device-to-device perspective in a disaster response network. They propose direct device interaction and test that user devices can securely communicate with each other with minimal to no infrastructure support. They prioritize users and nodes, as would a disaster response organization, as Primary Users and Secondary Users, attempting to overcome issues of relay selection, power allocation, and enhancing efficiency. Rigor in these solutions as it applies to the problem can be captured in an almost Venn-type nomenclature as we look at edge computing as it relates to hybrid cloud, and separately, to the scenario or use case of disaster response. Again, the potential for concrete solutions for the disaster problem provides promise for current and future research. They employ a cluster-based, hierarchical topology for multi-hop relay networks in order to cover the distance between source and destination devices. Their practical results show that by optimizing relay selection and beamforming vector, they are able to provide a more efficient solution which prioritizes priority users and enhances secondary users. CHAPTER 3 Background: Mission Critical First RespondersScenarioDevelopment of a thorough understanding of the problems faced by mission critical first responders enables researchers to create solutions tailored to the complications these organizations and individuals encounter. Through this chapter, we will present a realistic scenario based on the current policies and the capabilities, limitations, and challenges in place today. We also trace, from those policies, select processes, products, and technology related to disaster response. The contribution is that this provides a framework within which our solution must operate. Domestic Response to Disasters and EventsIf we take the case of a wildfire response, there are local, regional, state, and national, responders from the public sector who participate in such activities, depending on the order of magnitude. Added to this are multiple private companies, private parties, and non-government organizations (NGOs). An NGO may include organizations such as the American Red Cross or Samaritan’s Purse, and these autonomous organizations provide significant value for disaster response and relief operations. Collaboration between these organizations is essential. If we roughly pool responders into the domains of government (GOV), commercial/private (COM), and non-profit/NGO (ORG), a sample scenario provides visibility and clarity via a simplified interaction. Frequently the ORG is close to the problem and can provide information, coverage, and expertise not present in the other domains. In this scenario, a Red Cross team is located near a firefighter staging point and uncover a local need for more potable water. A commercial entity (COM) such as Walmart has tractor truckloads of palletized water available for delivery, and a government organization such as FEMA provides the coordinating authority for access to the scene and delivery (likely with financial authority for reimbursement from the disaster response budget). Each of these domains has its own information systems. FEMA falls under , Walmart under , and Red Cross under . FEMA assigns actions via a process and product known as the Mission Assignment. The Mission Assignments capture actions and collateral information. The below figure is a sample FEMA Mission Assignment activity.Figure 3 SEQ Figure \* ARABIC \s 1 1 FEMA Mission Assignment ExampleHere the example includes location, disaster event, description, agency, requested assistance, obligation estimate, and the date obligated. FEMA works as the controlling agency while the others provide the response actions. Given the parent domains for day-to-day information sharing, the challenge is how to get teams who have neither met nor worked together before to rapidly discover one another and collaborate beyond this initial face-to-face, radio and phone communications. The coordinating agency tends to have a good understanding of available organizations and resources, but they lack a means to connect responders rapidly via information sharing rmation Security Requirements and LimitationsFederal, regional, state, tribal, and local governments have closed systems which are not publicly accessible due to confidentiality, privacy, and legal purposes. Private companies clearly do not leave their internal resources open to the public, and likewise, non-profit / NGO parties have information systems unique to their organizations. Each rely on their parent organizations for “reachback” into content, processes, and products. Here we look at key policy, processes, products and technologies related to our scenario, hybrid cloud, and federation of identity. Key PoliciesHomeland SPD-5 CITATION Dep03 \l 1033 [59]President Bush enacted HSPD-5 to enhance the ability of the United States to manage domestic incidents by establishing a single, comprehensive national incident management system CITATION Dep03 \l 1033 [59]. The argument is that a single C2 solution would aid in simplifying and unifying incident response efforts. In addition to establishing DHS (and for specific scenarios FEMA) as the lead federal agency, it also provides the framework for relationships per our scenario:The Federal Government recognizes the role that the private and nongovernmental sectors play in preventing, preparing for, responding to, and recovering from terrorist attacks, major disasters, and other emergencies. The Secretary will coordinate with the private and nongovernmental sectors to ensure adequate planning, equipment, training, and exercise activities and to promote partnerships to address incident management capabilities. CITATION Dep03 \l 1033 [59](emphasis in bold added).This directive has provided the framework for disaster response for fifteen years, and outcomes show that it appears to provide better coordination across agencies and incident responders. National Response Framework CITATION Dep131 \l 1033 [60]Similarly, the National Response Framework CITATION Dep131 \l 1033 [60] provides guidance for response to disasters and emergencies. Interestingly it calls for “scalable, flexible, and adaptable” concepts in the response for aligning roles, responsibilities, and activities. We plan to model our solution on these qualities. The NRF scales from local to national events and priorities saving lives, protecting property, stabilizing the incident, and meeting human needs. The NRF calls for an Incident Command System (ICS) which has multiple functions (C2, operations, planning, logistics, finance/admin, etc.) and the establishment of Emergency Operation Center(s) at the appropriate local to federal levels. The impact of the NRF was to simplify the expected structure from incident to incident. Responders, for the most part, know to align to the established ICS via the EOC(s). Within the NRF are emergency support functions (ESF) of which ESF #4 is Firefighting. FEMA/US Fire Administration and the US Department of Agriculture/US Forest Service are the ESF coordinators. The National Interagency Fire Center (NIFC) CITATION Nat1 \l 1033 [61] provides a focal point for coordinating mobilization of resources for wildland fires in the US, and they work via the National Interagency Coordination Center (NICC). Other organizations support this ESF, such as the National Wildfire Coordinating Group CITATION Nat \l 1033 [62]. This organization makes up nine-member organizations from the federatl to local level who support wildfire response. They do a thorough job of capturing the ICS forms and products CITATION NWC \l 1033 [63] relative to wildfire disasters. One such aid, as an example, is an Incident Check-In List which captures the names of personnel and organizations participating in a given incident. Key Processes and ProductsNational Incident Management SystemThe purpose of the NIMS is to provide a common approach for managing incidents. CITATION FEM142 \l 1033 [64] The President of the United States directed the Secretary of the Department of Homeland Security (DHS) to establish a National Incident Management System (NIMS) via Homeland Security Presidential Directive-5 CITATION Pre03 \l 1033 [65]. The NIMS provides a standardized set of incident management practices. It emphasizes a consistent approach to operational structures and supporting mechanisms and an integrated approach to resource management. CITATION FEM142 \l 1033 [64]As one official stated, “every incident is a local incident.” CITATION Sta14 \l 1033 [20] Incidents typically begin and end locally, and the goal throughout is to manage an event at the lowest possible geographical, organizational, and jurisdictional level. As escalation occurs, success depends on the participation of multiple jurisdictions, governmental levels, functional agencies, and the multiple emergency-responder disciplines. Reponses require significant coordination across this broad spectrum of these organizations and activities. DHS, via NIMS, claims to provide a comprehensive national approach to improve the effectiveness of emergency and disaster response. Incident Command System (ICS) CITATION FEM1 \l 1033 [66]The ICS is the management system designed for integrating and organizing response to events with a common structure and approach. Through this standardization, FEMA provides common processes and products CITATION FEM10 \l 1033 [67] to manage incident response. ICS enables effective and efficient domestic incident management by integrating facilities, equipment, personnel, procedures, and communications CITATION FEM171 \l 1033 [68]. The five major functional areas of ICS include command, operations, planning, logistics, intelligence/investigations, and finance/administration CITATION FEM171 \l 1033 [68]. Mission Assignment ProcessWhen responders, the public, or any organization associated with an incident establishes a need, the ICS provides an approach to submit, vet and assign the need to responders. This follows a rough process including:Needs AssessmentNeeds AnalysisAction Request Form CITATION FEM08 \l 1033 [69]: A form used to request Federal assistance.Resource Request FormCITATION FEM2 \l 1033 [70]: A form used to formalize request between the incident command and resource. Mission Assignment CITATION FEM3 \l 1033 [71]Relief and Assistance ActionsPerformance Monitoring CITATION Dep144 \l 1033 [72]As indicated above, the alignment of federal resources (e.g. funds) to validated needs is performed via the mission assignment process. FEMA employs mission assignments to task and reimburse other federal departments and agencies when they provide assistances directly to fill a need during a disaster or emergency CITATION FEM14 \l 1033 [73]. Given the routine nature of the types of assistance requested, FEMA determined in the mid-2000s to anticipate requests and develop a pre-scripted mission assignment. FEMA and other responders prepare these in advance to facilitate rapid response. As an example, during a wildfire, responders will typically request fire-fighting fixed and rotary wing air assets to assist in mitigation of the fire’s impact. This resource is a candidate for a pre-scripted mission assignment (PSMA) at the onset of the event. Since 2006, FEMA has increased the number of PSMAs from 44 with two federal agencies to 291, in coordination with 31 federal agencies. CITATION Sta14 \l 1033 [20] CITATION FEM14 \l 1033 [73] PSMA support includes a full spectrum of resources: from heavy-lift helicopters from the Department of Defense, generators from the U.S. Army Corps of Engineers, Disaster Medical Assistance Teams from Health and Human Services (HHS), and Emergency Road Clearing Teams from the U.S. Forest Service CITATION FEM14 \l 1033 [73]. Battle RhythmAdopted from the military, the battle rhythm is the 24-hour daily cycle for operations, briefs, and turnover of resources. As an example, a battle rhythm may include a twice-daily public affairs brief.Geospatial Information Sharing (GIS)GIS provides geographically-based visualizations of products related to the event. As an example, a wildfire GIS product could include burn area, meteorological conditions, daily-change comparisons, population density, topographical information, etc. Public InterfaceUpdating the impacted and interested public is an essential component to the disaster relief process. The incident commander may have desired actions of the population which can be communicated via various means. Some examples include locating (disaster shelters, stay inside warnings, etc.), support (donation centers), or impacted citizen communication (e.g. instructions for evacuees). Key Technologies Homeland Security Information Network (HSIN).FEMA provides a glimpse into their sensitive but unclassified environment via the HSIN CITATION FEM \l 1033 [74]. HSIN provides alerts, training, documents, geospatial information (GIS), instant messaging, workflow, and conferencing. HSIN is a FEMA-administered system requiring individuals to create a username and password for access. The governance revolves loosely around community of interest (COI) sponsors who approve and validate access. Users have a 90-day “stale” period which trigger account deactivation, yet there is no mechanism to validate participant status once the initial account is created. As an example, a Red Cross employee terminated for financial misconduct the day an event starts would potentially have continued access to HSIN. WebEOCThe Intermedix software solution WebEOC CITATION Int \l 1033 [75] (short for Web Emergency Operations Center) is a prevalent solution fielded to many of the local, state and federal organizations providing emergency services and disaster response. WebEOC features include content supporting historically significant products in the disaster response realm. The event reporting function is essentially an electronic log of event-related information. Situational awareness functionality enables a situation report (SITREP in DoD) formatted entry to provide an update on a given scenario or situation. The resource management function maps closest to the mission assignment process as it enables full lifecycle entry and fulfillment of request from multiple platforms (with mobile device being one of the most essential). The duty log is a primarily text-based function mirroring entries in a traditional logbook. Lastly, WebEOC provides after action reporting functionality which enhances the organization’s ability to capture and respond to queries after an event. WebEOC has both cloud-hosted and private-cloud (on premise) solutions to support organizations participating in emergency and disaster response. Each WebEOC administrator creates accounts for discrete WebEOC instances, and there is no federation of technology or identities across platforms. Again, a user who has lost trust from a parent organization will maintain his or her WebEOC account indefinitely or per the local WebEOC administrative policies. FEMA Application Authentication SystemInternal to DHS and FEMA is a trust-based federation system called AppAuth. This solution intends to provide single-sign-on (SSO) to internal DHS individuals to move across applications seamlessly. This system operates on two-way external trusts and is moving to AD forest level trusts. The goal is to eventually set up a federation trust framework with AppAuth as the hub. CITATION FEM17 \l 1033 [76] External users (e.g. our COM and ORG domains) do not have access to the GOV-internal system. Other systemsAt the local, state, regional, tribal, and federal levels, several systems, web sites, social media accounts, and other solutions exist for incident response communications. Additionally, government, military, commercial, nonprofit, and other organizations maintain abilities to leverage incident response or day-to-day systems to communication during an incident. These typically include “home organization” datacenters or “private cloud” infrastructure.In practice, many disaster response communication efforts proceed through a “lowest common denominator” CITATION Col05 \l 1033 [22], CITATION Sta14 \l 1033 [20] approach. This includes “cell phones” and “email with attachments” via a “who you know” system of providing contacts CITATION BGe10 \l 1033 [77], CITATION Col05 \l 1033 [22], CITATION Sta14 \l 1033 [20]. This approach, seen in several events historically, is both inefficient and time consuming. Challenges in Disaster Response“Many After Action Reports (AARs) and Observations and Lessons Identified have been captured. Yet a large percentage of the issues identified in HADR activities are re-identified in subsequent operations CITATION MIl14 \l 1033 [78].” The director of DoD’s US Pacific Command’s disaster response after actions captures this perception of “disaster response déjà vu” as subsequent teams experience similar challenges and issues. Confirmed by other incident commanders, responders, and facilitators CITATION Sta14 \l 1033 [20], CITATION Col05 \l 1033 [22], CITATION BGe10 \l 1033 [77], CITATION Cec13 \l 1033 [79] the complexity of disaster response, impact to existing infrastructure, and lack of universally-resilient processes and tools, response communications issues have recurring themes. These recurring issues often result in delayed response, loss of life and destruction of property, eventually resulting in impaired disaster response efforts. Nishiyama et. al CITATION Nis17 \l 1033 [80] capture an excellent assessment of post-disaster communication impact (leveraging such events as the Great East Japan Earthquake of 2011). Below the time-phased demand on the communication infrastructure demonstrates demand and throughput, to which they propose a more intelligent yet secure approach which provides necessary resilience. Figure 3 SEQ Figure \* ARABIC \s 1 2 Demand for information communication technology services after the strike of disaster. CITATION Nis17 \l 1033 [80]While the demand for information communication technology and information sharing seems somewhat obvious, a less apparent challenge is that of protecting critical information from undesired disclosure. At one end of the spectrum, Phillips et al. CITATION PHi02 \l 1033 [81] capture a scenario for international disaster response wherein participants are partners in one crisis and adversaries in another. Information protection is at a premium in this case. At the other end of the spectrum, Palen and Liu CITATION Pal07 \l 1033 [82] focus on opening the avenues for persistent citizen communication with the response hierarchy. They also find challenges in interfacing with the C2 models which do not necessarily accommodate this raw information sharing (and its potential exposure of privacy information (PII)). Likewise. Lovejoy and Saxton CITATION Lov12 \l 1033 [83] find that non-profits increasingly rely on social media as a disaster relief tool. To ignore the potential impact would be a mistake for government responders, but the challenge of implementing secure information sharing is very real. In summary, key challenges related to our research include:Disaster response “déjà vu,” e.g., repeating past mistakesRapid information sharingTrusted identity Siloed information.As with all information systems solution, our approach must continue to balance the often-competing areas of confidentiality, integrity, and availability. ConclusionWhile this is not a comprehensive study of all information technology solutions available for disaster response, our research provides a good sample of how national policy has impacted the development of interagency solutions for disaster response. Here we provide a summary of the policies, processes, products, and technologies which contribute to our disaster response scenario. We also capture key challenges related to our scenario and research. CHAPTER 4Hybrid Cloud ComputingOur focus will be on the cloud deployment models and suitability to our problem. Public cloud is purely commercial-provided, private cloud is solely user-provided, and community cloud is most closely aligned to a commercially-provided model, only with a focus on a subset of special case users. One such case is government community cloud as provided by companies such as Microsoft CITATION Mic15 \l 1033 [84] and Amazon CITATION Ama15 \l 1033 [85]. Lastly, the hybrid cloud model combines two or more of private, commercial, and community clouds. Our proposed architecture combines one or more community cloud nodes with the responder private cloud locations, which equates to a hybrid cloud deployment model. ContributionGiven an understanding of the mission critical first responder scenario, this section captures the current and emerging state of hybrid cloud computing. Given the requirements for resiliency, scalability, redundancy, and cost-effectiveness, we will establish that a hybrid cloud model provides the best alignment to our work. Cloud Computing ModelNIST CITATION Mel11 \l 1033 [3] captures a cloud model with five essential characteristics, three service models, and four deployment models. The below provides an overview of this model.Figure 4 SEQ Figure \* ARABIC \s 1 1 Visual Depiction of the NIST Cloud Computing Definition CITATION PMe11 \l 1033 [86]Government, private sector, and academia tend to have a consensus for this model CITATION Smi13 \l 1033 [87] CITATION Dav14 \l 1033 [88]. Detailed discussion on these characteristics, service models, and deployment models is widely available CITATION PMe11 \l 1033 [86] CITATION Beh12 \l 1033 [89] CITATION Tre13 \l 1033 [90] CITATION Rit09 \l 1033 [91] CITATION Kun11 \l 1033 [14]. From a service delivery perspective, it is important to be familiar with the components of each of the cloud service models. This answers the question, “who is responsible for delivering this service?” From CITATION PCI13 \l 1033 [92], the cloud service models essentially provide a “trade-off” of who runs the service. The services are delivered either by the cloud service provider or the user organization. As an example, for Software as a Service (SaaS), the provider delivers most of the service stack. For Infrastructure as a Service (IaaS), a significant management burden is placed on the user. Deployment model is the final consideration. Given this study on hybrid cloud in the public sector, we are essentially addressing the above service models in a hybrid construct. Hybrid computing consists of one or more private clouds (often using the legacy “datacenter”), typically operating on the users’ premises, mixed with a public cloud on the cloud service provider’s premises.Public Sector Cloud Computing Adoption“Cloud First”In 2011, Federal Chief Information Officer Vivek Kundra published an unprecedented policy related to cloud computing: Federal Cloud Computing Strategy CITATION Kun11 \l 1033 [14]. Leveraging his academic and industry experience, and noting the inefficiencies in government data centers, he promoted the promise, “Cloud computing has the potential to play a major part in addressing these inefficiencies and improving government service delivery. CITATION Kun11 \l 1033 [14]” Beginning in 2011, this change in policy initiated movement within the government from a datacenter-centric view to what became known as a “cloud first” strategy. Instead of asking “should we move to the cloud,” the policy essentially flipped the perspective, “why should we not move to the cloud?” ChallengesAs indicated by the Assistant Inspector General for IT Audits and Computer Crime Investigations at the U.S. Department of Education, “Unfortunately, I think there was a rush to the cloud for the federal government, and I don’t think … all aspects of it were well thought out.” CITATION Jon14 \l 1033 [93] Most federal CIOs face more risk from security compromise (presumably from poor cloud implementation) than from lack of “status quo” datacenter cost and operations. As such, many shy from moving to the cloud in the near term. As Gartner CITATION Hol16 \l 1033 [94] finds, however, there is now an inflection point in federal cloud adoption as federal CIOs experience an increase in confidence with cloud-based applications (e.g., enterprise email). Balancing Public and Private Cloud ComputingContinuing the federal cloud discussion, Kundra complemented the Federal Cloud Computing Strategy with an overarching 25 Point Implementation Plan to Reform Information Technology Management CITATION Kun10 \l 1033 [95]. This policy included pursuing datacenter consolidation along with accelerated cloud adoption. In 2017 and 2018, the Deputy Secretary of Defense provided guidance CITATION Sha18 \l 1033 [96] for accelerating enterprise cloud adoption, which includes increased use of commercial cloud providers (public and community cloud). With the intended outcomes to lower costs, improve performance, and increase lethality, the services and agencies within the Department of Defense have available avenues to pursue certified public and community cloud solutions. Cloud Cybersecurity FrameworksFederal Cybersecurity Policies and PracticesWith cyberattacks increasing against the US CITATION Mos09 \l 1033 [97], the federal government has moved toward a Risk Management Framework (RMF) CITATION NIS18 \l 1033 [98] for information assurance. In contrast to the previous zero- to no-defects Information Assurance Certification / Accreditation Program, the RMF balances security and risk management throughout the system lifecycle. Through this framework, the federal government and many related organizations subscribe to established standards for security. From CITATION Shi17 \l 1033 [42] and CITATION Clo17 \l 1033 [99], the Cloud Controls Matrix (CCM) CITATION CCM \l 1033 [100] provides security principles for cloud vendors and assists cloud customers in assessing the security risk of a provider. The Cloud Security Alliance (CSA) CCM provides a framework which gives an understanding of security concepts that are aligned to the CSA guidance in thirteen domains. CCM relates to other industry standards, regulations, and controls such as the ISO 27001, ISO 27002 CITATION Int01 \l 1033 [101] and ISACA CoBIT.ISO 27000 SeriesPer ISO 27000:2014, the family of international standards for information technology – security techniques –information security contains three components: confidentiality, integrity, and availability CITATION Int01 \l 1033 [101], CITATION Int10 \l 1033 [102]. Agreement on a common definition of these security components is essential for providing the same architectural view of these scenarios.Confidentiality: the property that information is not made available or disclosed to unauthorized individuals, entities, or processes. Regardless of the access point (mobile, desktop, remote, from servers, internet, etc.), confidentiality presumes a sense of end-to-end assured protection of information being accessed, both in transit and at rest. Integrity: the property of accuracy and completeness. The implication with integrity is that the contents of the data are intact, unmodified, and reliable.Availability: the property of being accessible and usable upon demand by an authorized entity. Without the aspect of availability, the information is not readily accessible by those needing access or ability to interact with the data[7].FedRAMPPerhaps the single-most impactful “gate” for cloud adoption is the Federal Risk and Authorization Management Program or FedRAMP CITATION FED16 \l 1033 [15]. Proposing to be “secure, mobile, and nimble,” FedRAMP provides both a process and a certification for accelerating cloud adoption. Once a cloud solution is certified FedRAMP for one government customer, it becomes available to all government customers (“do once, use many times”) CITATION FED16 \l 1033 [15] from a certification and RMF approach. The FedRAMP Marketplace has a catalog of currently certified vendors and solutions at CITATION Fed18 \l 1033 [103]. Preferred Cloud ApproachAs captured in CITATION Placeholder1 \l 1033 [7], CITATION Gar17 \l 1033 [18], CITATION Sta14 \l 1033 [20], CITATION BGe10 \l 1033 [77] , CITATION Mey13 \l 1033 [104], few organizations routinely participating in disaster response today desire to make major investments and changes to their current environment. The constraint of “minimal change” to the de facto architecture from CITATION Placeholder1 \l 1033 [7] is very real given limited budgets available to public and private organizations alike. That said, each of our domains (GOV, COM, ORG) continues to embrace cloud computing as providers align their cloud offerings to organizational demands. These often include the compliance areas discussed earlier to balance the confidentiality and integrity components of security. Lastly, each domain we studied is under increasing pressure for data center consolidation and cost savings from “private cloud” solutions. Each has a de facto identity management solution in place which is compatible with extending to a federated identity approach. They key barrier for identity implementation is policy change, and there continue to be few barriers to moving components of the on-premises infrastructure to the public or community cloud.Hybrid cloud, the integration of NIST’s private cloud and public cloud CITATION PMe11 \l 1033 [86] (or private cloud and community cloud), is a logical architectural model for our use case of disaster response. This provides the benefit of leveraging existing on-premises, private cloud applications, data, and identity solutions while gaining the capabilities offered by public cloud in terms of scalability, resilience, and especially cost. The solution we propose will have a small footprint and cost for the disaster information sharing solution when not in use, and rapid elasticity and scalability when a disaster occurs. ConclusionHere we have captured exciting new alignment of demands and capabilities not available just a few years ago. Desire for innovative information sharing platforms based on cloud technologies now have accredited solutions from providers which meet stringent demands for security and compliance. We will find in the next chapter that this “perfect storm” of capabilities has an underlying identity framework which can potentially unleash the promises of cloud benefits while maximizing existing de facto solutions and standards. CHAPTER 5Federated IdentityFederated Identity Trajectories. As enterprise fragmentation CITATION Kre12 \l 1033 [105] and social networking grow in practice, there is an increasing need to integrate organizational and personal identities via a much larger scale than was previously envisioned. Enterprise and commercial trends continue to drive innovation in the emerging identity federation trends and standards. With increasing use of cloud and internet-based applications, use of federated identity solutions has gained traction CITATION Der13 \l 1033 [106]. Contributions: In this chapter we uncover the recent advances and standardization in federated identity, trace the roots of the current state of the art for identity federation, capture trends that are driving emerging solutions, and provide the necessary underlying framework through which federated identity applies to our use case. Background Identity, Access, Authorization, and Identity ManagementBefore one can fully understand the federation of identity, the areas of identity and access management (IdAM) must be well-comprehended. This section provides that foundation and current definitions essential for a discussion on federated identity. Identity, at its most basic form, is a set of characteristics forming the essence of who one is CITATION Der13 \l 1033 [106]. Identity Management. Identity and identity management are cornerstone technologies for securely accessing cloud resources. The ITU Focus Group on Identity Management defines identity management CITATION Int14 \l 1033 [107] as “the management by trusted providers of trusted attributes of a subject.” Implemented correctly, identity management enables trusted access to information and provides a foundation for inter-organizational collaboration. Additionally, it provides non-repudiation of actions performed.Identity Management Lifecycle. In their Considerations for Identity Management in Public Safety Mobile NetworksCITATION Nat14 \l 1033 [108], NIST summarizes the lifecycle of identity management. It is important that all participants have a common understanding of this framework to set the conditions for successful identity federation and information exchange. The lifecycle approach applies to informal commercial solutions provided by social networking IDPs as well as extensive Defense Department Public Key Infrastructure solutions.Registration: Application for credentials. Information about the individual is verified to establish a level of assurance. (Here we emphasize verifiable identity CITATION Mey131 \l 1033 [6]).Issuance: Creation of the token and identity pair bound by a credential.Usage: Use of the identity to gain access.Expiration: Lifetime based on token type and security requirements. Expired credentials are no longer valid.Revocation: Invalidated credentials before end of life. Examples include termination of employee and lost credentials.Suspension: Temporarily invalidated credentials. Re-issuance/Updating: Change in credential based on multiple factors (e.g., promotion, change in role, additional access, etc.)Authentication. The process of verifying whether one is who he says he is authentication. Validating an individual or identity is part of secure information access practices. Authentication includes identification and verification, and this is foundational to the solutions we will propose in this research. Verifiable identity CITATION Mey131 \l 1033 [6] becomes essential when we move from social media to systems used for formal disaster response missions. Means of authentication in place today include username and password, biometrics, digital certificates (unique key pairs), ticketing-based systems (e.g., Kerberos), token-based, and others, to include multifactor authentication (a combination of two or more of the above.) Many use the phrase “something you know, something you have, and something you are” to classify components of authentication CITATION Der13 \l 1033 [106].Identity and Access Management. Also, IdaM or IAM, this is the approach to enable the right individual to access the right resources at the right times for the right reasons CITATION Gar19 \l 1033 [109]. In our scenario, there may be valid users who do not have the authority to interact in given roles in the disaster response. This is controlled via valid IdaM processes. Identity Providers. Identity providers (IDP) establish and manage a given user community’s digital identities CITATION Nat12 \l 1033 [110]. There are multiple IDP models and in place to meet varying needs for identity and access management. For the purpose of this research, the authentication solutions and IDP models are categorized according to the number of parties involved in the authentication process. Below are three models from which other authentication frameworks may be extracted CITATION Nat12 \l 1033 [110].Two-party IDP model. In this model, the two parties involved in authentication are the service provider and the user. The service provider also acts as the IDP. Most traditional systems follow the two-party IDP model, and this model works quite well for an individual organization. In this model, the user registers with the service provider. A good example of this model is web-based email service. A user requests the service and is issued a username and password. These digital credentials are used each time the user requests email service via a client (mobile device, tablet, laptop, and desktop). The user must remember these credentials for each provider, and this model has led to the “multiple usernames” and “multiple passwords” problem encountered today. The two-party IDP model is rarely part of a larger federation solution due to its intended design. Three-Party IDP Model. Like the above, a three-party model includes the user and the service provider, but also includes an independent IDP. Once authenticated with the IDP, the IDP issues an assertion to the service provider that the user successfully authenticated. Authentication, Authorization, and Access. Rountree highlights that the concepts of authentication and authorization are at the core of federated identity CITATION Der13 \l 1033 [106]. Many incorrectly combine the two into one concept of “authentication and authorization CITATION Ver01 \l 1033 [111],” yet it is important to develop an understanding of the differences and roles when devising practical implementation. Authentication is the mechanism for verifying identity (or ascertaining “knowledge”) of an individual or device (“user” or “computer”). I authenticate who you are based on some credentials or mutual understanding. Authorization is the process used to determine the “what…” services(s) can be accessed. I authorize you actions or access based on the authentication and other factors related to your need to conduct actions. As an example, the Department of Defense (DoD) vets employees based on proof such as birth certificates, passports, drivers licenses, and other verifiable documents, and assign identity and access rights via a “common access card.” A common access card (or “CAC”), is a "smart" ID card for active-duty military personnel, Selected Reserve, DoD civilian employees, and eligible contractor personnel CITATION Def14 \l 1033 [112]. Figure 5 SEQ Figure \* ARABIC \s 1 1 The Department of Defense CAC is used for Authentication, Authorization, and Access control.While some organizations separate physical and virtual access control mechanisms, DoD includes both physical access (e.g. building entry) and virtual access (network login and access) via the same physical card. While the roles of authentication, authorization, and access are included on the same physical platform, the technical mechanisms are different for each function. To better represent the different activities, the following scenario shows how they differ. The scenario includes a DoD user logging in (authenticating) by using the DoD Public Key Infrastructure (PKI) architecture and then gaining authorization and access to resources. The user inserts the physical CAC (the size of a credit card) into a CAC reader. The CAC reader interfaces with the physical integrated circuit chip (ICC) which contains information about the user. The owner information includes data such as name and email address, and the ICC also contains a multi-digit personal identification number (PIN) and potentially multiple PKI digital certificates. When the PIN is entered by the user, the system matches it to the PIN on the card. This provides one factor of authorization in a two-factor model (“something you have” plus “something you know” CITATION Ras14 \l 1033 [113]). The card is the possession, while the PIN is something known only to the user. Adaptive Access Control. Gartner researchers apply the term "adaptive access control" to cover the range of “adaptive” authentication methods that include any “composite, risk-based, step-up, trust elevation, automatic or continuous authentication mechanisms CITATION Rud13 \l 1033 [114].” Key to the range of access controls is the underlying identity verification processes and standards employed by an organization.Federated Identity definition is critical to this paper, so developing an understanding is essential to providing a proper foundation. Growing federation technologies and unique business circumstances hamper the ability for organizations to federate in a standardized manner. According to NIST, there is no uniform approach to the federation process CITATION Nat12 \l 1033 [110].Gartner defines federated identity as using an identity from one domain to access resources in another domain CITATION Rud13 \l 1033 [114]. Others see federation as providing access across trust barriers. Consumers equate federation with SSO and simplified login. Why Federate? Federation addresses many identity and access management challenges discussed. Several variables apply in identity solutions and have changing levels of importance depending on the scenario. For example, most organizations prefer the “come as you are” model of communications. Responders cannot afford to make major changes to their systems in preparation or during an event due to probable internal disruptions. For example, establishing/changing account names, passwords, or email addresses cause disruption in access management. Variables may include time to begin mission response, levels of security classification, numbers of communities of interest, response priorities, and other relevant factors. CITATION Placeholder1 \l 1033 [7]From a usability perspective, federation allows single-sign on (SSO). SSO is familiar in the consumer paradigm (e.g., logging in to a blog or shopping site with Facebook or Google credentials). SSO brings simplicity to our scenario.More importantly for this research, federation leverages two key aspects of security: authoritative source validation and verifiable identity. We discuss each briefly.Authoritative SourceWhen one creates a social media account, there are many ways to identify the individual or account. Unfortunately, Twitter, Facebook, WeChat, and others have few means to be the authority on one’s identity. As an example, it is fairly easy to create the identity for one’s pet in a social media account. While social media may represent one aspect of one’s identity, there is currently no avenue for these platforms to act as the source of the individual’s identity. Upon federation with verifiable entities (discussed below), the IDP acts as the authoritative source for identity. As an example, an employee of FEMA (GOV) who participates in a response uses FEMA as his or her authoritative source. In other words, FEMA represents the individual and accurately portrays their status with the organization to include their role or other attributes. Likewise, if FEMA terminates the same employee, we can look to FEMA to accurately represent their status as “no longer an employee here.”Verifiable IdentityRelated to authoritative source is verifiable identity. Verifiable identity asks the question, “how do I know this is you?” Referencing the social media example, while Facebook provide may act as an Identity Provider, how does a relying party know Facebook is providing a valid identity? There is little to no assurance, yet frequently, social media accounts are leveraged as IDPs for shopping, new social media accounts, and even for university level records keeping. Relying parties in this case tend to have a lower expectation of validating actual identity but rather having a relative value to leverage to offload identity creation and lifecycle management (primarily a user versus provider preference). Oddly, in the disaster response environment, given the simplicity of social media and cloud accounts, and the reliability of commercial cloud providers, it is not uncommon for responders to maintain unverifiable identity accounts as primary or alternate contacts during disaster response operations. Many find this reliability outweighs the security concerns, and users frequently back up their formal organizational identities from government, commercial or nonprofit entities with “” and “” accounts. The issues of authoritative source and verifiable identity become clear in the scenario where such a user is terminated or leaves a given organization yet uses one of these “off the record” accounts to continue operating in the previous role, unbeknownst to the peer users. Federated Identity StandardsFederated identity has evolved over the past several years to provide standards-based solutions adopted by various providers and organizations. Rountree CITATION Rou13 \l 1033 [115] provides a good discussion of the federated identity standards, evolution, and a workable model which is widely-accepted. These include but are not limited to:OpenID CITATION Ope15 \l 1033 [116]: Provides the framework for information exchange between an identity provider and a service provider. The current OpenID Connect rides on top of OAuth 2.0 CITATION Int12 \l 1033 [117] and uses a more lightweight RESTful approach than XML-based standards such as SAML (driving adopting in the mobility area). OAuth 2.0 CITATION Int12 \l 1033 [117]: Enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. (OpenID enables authentication while OAuth ensures authorization).Security Tokens: Vehicles used to pass information between identity providers and service providers CITATION Rou13 \l 1033 [115]. Common security tokens include Simple Web Tokens, JSON Web Tokens, and most familiar, Security Assertion Markup Language (SAML). SAML 2.0 CITATION Org05 \l 1033 [118]: Enables the communication of user authentication, entitlement, and attribute information. SAML allows entities to make assertions regarding the identity, attributes, and entitlements of a subject (e.g., a human user) to other entities, such as a partner or another enterprise application. SAML 2.0 includes assertions, protocols, bindings, and profiles and has proven quite robust in secure identity sharing.Web Service Specifications (WSS): This series of specifications provides framework for designing, building, and protecting web services CITATION Rou13 \l 1033 [115]. Of interest in these specifications are the WS-Security (which derived Simple Object Access Protocol (SOAP), Kerberos, and X.509 as examples CITATION OAS06 \l 1033 [119]), WS-SecurityPolicy, WS-Trust, and WS-Federation.Windows Identity Foundation CITATION Mic151 \l 1033 [120]: Microsoft’s approach for implementing WS-Trust and WS-Federation using claims-based applications and token services. Notable output products using this framework include Active Directory (AD), AD Federation Services (ADFS), and Azure AD. Components of FederationFrom CITATION Placeholder1 \l 1033 [7] and CITATION Mal08 \l 1033 [121], federated identity requires four components:User (which may have one or more personas).User agent: a browser or application running on a PC or mobile device. The user agent (UA) acts on the user’s behalf to mediate identity exchanges.Service provider (SP): a web-based application that directs identity information to the identity authority or provider. This is often referred to as the relying party (RP).Identity provider (IDP): networked location that stores identity attributes to share with users and SPs.Federated Identity TechnologiesFederation has become more commonplace in both the commercial (e.g., social media) and business environments. While public sector has been slow to adopt, federation is becoming more frequently-used, but typically in government-to-government scenarios only. Below is a sample of popular technologies in use today CITATION Gre17 \l 1033 [122]. Okta: Okta identity management via multitenant Identity-as-a-Service (IDaaS) model. Ping Identity: PingFederate, PingAccess, PingOne Cloud (IDaaS) and PingID.Microsoft: Azure Active Directory (IDaaS), Active Directory Federation Services, and Microsoft Identity Manager.Oracle: Oracle Access Management (OAM) and Identity Cloud Service (IDCS) as IDaaS. IBM: IBM Security Access Manager (ISAM) and Cloud Identity Service (CIS).CA Technologies: CA Single Sign-On and CA Identity Service.Social IDPs (Google, Facebook, etc.) on protocols such as OpenID and OAuth.InCommon: A common trust framework for US education and research communities (consortium leveraging multiple technologies like Microsoft and Cirrus Identity, and Shibboleth and SAML integration). CITATION InC18 \l 1033 [123] As a practical example, the University of Colorado at Colorado Springs uses a combination of Microsoft ADFS, Azure AD, Ping, and Oracle. Federation in the Disaster Response ArenaAlignment of our approach to de facto standards will prove important to minimize disruption. FEMA: The current identity architecture at FEMA includes Active Directory and ADFS on-premises plus cloud identities in Azure Active Directory (which synchronizes to on-premises identity). While internal services have two-way domain trusts, there is no external federation. Walmart: The current identity architecture at FEMA is hybrid identity, employing Active Directory on-premises and Azure Active Directory for cloud use. There are multiple interoperable third-party solutions for various siloed applications within Walmart, and they employ a business-to-business (B2B) model for trusted suppliers and partners. Red Cross: CITATION Jua13 \l 1033 [124] Red Cross has a centralized CIO function and distributed management across worldwide entities. Their public-facing applications solicit donations and coordinate disaster response activities internal to the Red Cross organization (e.g., contact loved ones, provide shelter, blood supply/drives, and military services). Externally, they participate as called and task organized in every major disaster in the United States. This participation is highly decentralized, and the interaction with local government organizations is based on longstanding relationships and Red Cross’ international and national charters CITATION Ame17 \l 1033 [125]. Red Cross is also a “primary agency” for the mass care emergency function and a “support agency” for other areas of the National Response Plan. Their hybrid identity includes on-premises AD and ADFS (crossnet.) with federation on Azure AD/O365 services (365fs.).Federated Identity CybersecurityFederated Identity Cybersecurity ConsiderationsThreats against federated identity continue to mature as more secure solutions are developed. Each interface in the architecture is vulnerable to a myriad of compromise techniques, and this requires continuous vigilance in defending against attack.Fortunately, as the growth of cloud computing continues, the research related to mitigating threat vectors matures. Khattak et al. CITATION Zub10 \l 1033 [126]provide a robust assessment of three core vulnerabilities in federated identity systems. They characterize these as users’ identity theft, misuse of user identity information via single sign-on facility in identity providers and service providers, and trustworthiness of subject. Each of these threats has multiple threat vector qualities that are recognizable to those familiar with cybersecurity studies. Related to identity theft, Warren et al. CITATION War11 \l 1033 [127] characterize a very relevant example with a familiar social networking system (provider). One finding includes that “if Facebook user credentials are compromised then access to other [federated] sites is also enabled and that a user’s online identity can be assumed CITATION War11 \l 1033 [127].” Another example is the manipulation of third party applications used by Facebook and the redirection of users to malicious sites and away from the Facebook ecosystem.Related to the above discussion on authoritative source and verifiable identity, we will add aspects of security to our scenario vis a vis a discussion on federated identity threats.Threats to Federated Identity SolutionFrom CITATION Shi17 \l 1033 [42] and CITATION Clo17 \l 1033 [99], the Cloud Controls Matrix (CCM) CITATION CCM \l 1033 [100] provides security principles for cloud vendors and assists cloud customers in assessing the security risk of a provider. The Cloud Security Alliance (CSA) CCM provides a framework which gives an understanding of security concepts that are aligned to the CSA guidance in thirteen domains. CCM relates to other industry standards, regulations, and controls such as the ISO 27001, ISO 27002 CITATION Int01 \l 1033 [101] and ISACA CoBIT.Khattak et al. CITATION Zub10 \l 1033 [126] propose a threat model for federated identity systems which fits well with our architecture. These include:Identity theft: User credentials or identities in response networks risk compromise by typically attacks, such as phishing, which attackers can use to compromise or impersonate activities on the system. Misused identity information: Given we will propose identity federation via the use of identity providers and relying parties, these could be misused by those providers or by bad actors posing as those providers.Trust relationship vulnerabilities: Related to the above, the misuse of security tokens exchanged as part of the claims-based federated authentication would compromise our architecture. Session hijacking and token replay are included here as well.Using this initial framework, we will develop our solution against this threat model to federated identity. ConclusionIn this chapter we capture the emergence of federation identity capabilities as mature enough for our scenario. The role of verifiable identity ensures a broad understanding across our scenario that we have the right players in disaster response. The guarantee of identity and access lifecycle management across our trusted partners ensure a level of security across a distributed scenario. Federated identity standards and their alignment to our scenario appear to be suitable to meet goals of shared information sharing, and we will have to assess the alignment with our chosen hybrid cloud architecture as well.Chapter 6Alignment of Hybrid Cloud Federated Identity SolutionsIntroduction One essential question for the alignment of federated identity to cloud computing is the acceptability of this proposed model. Fortunately, in this section we will find that federation is in fact one of the key enablers for seamless operations in a hybrid cloud scenario. One technology enables the other. ContributionsWe provide an alignment of the previously-discussed hybrid cloud architecture to the approach of federated identity. This provides the first broad federated identity hybrid cloud approach to the problem of disaster response. Alignment of Community CloudThe NIST Cloud Definition discussed previously include hybrid cloud as a “composition of two or more distinct cloud infrastructures (private, community, or public)…” CITATION PMe11 \l 1033 [86] (emphasis added). While public cloud services abound commercially, the alignment to our scenario requires certification with government standards such as FedRAMP. As such, the hybrid cloud model used here will include one or more “host” on-premises “private” clouds (representing GOV, COM, and ORG) plus a community cloud with certification to the level required by the host organization (in this case FEMA). Given the FedRAMP requirement for the US federal government solutions (here FEMA as part of DHS), the community cloud provider would be one of the authorized products on the FedRAMP Marketplace CITATION Fed18 \l 1033 [103]. O365 has a government multi-tenant solution SaaS authorization at the moderate level, and this is suitable for our research. As part of the research grant, our Azure research subscription and MSDN subscriptions are not for government use, and we will build our research solution on commercially-available Azure and O365 respectively. Alignment of Federated IdentityThere are multiple technologies to use for federation, as was shown in the previous chapter. Given the broad use of ADFS in the private clouds of each of our notional organizations (FEMA, Walmart, and Red Cross), and the use of Azure AD by our cloud resources, we plan to use ADFS and Azure AD for our research. Practically, making the most use of current de facto standards at each of these organizations will potentially speed adoption.ConclusionBuilding on the hybrid cloud discussion in REF _Ref509158457 \r \h 0 and federated identity research in REF _Ref509158478 \r \h 0, here we provide a higher level of granularity for our proposed solution. The optimal choice appears to be a hybrid cloud using existing on-premises federation technologies and a community cloud for the response site. CHAPTER 7Deploy a Hybrid Cloud Federated Identity SolutionIntroductionChoosing to build our solution in Azure and O365 enabled us to use a hybrid cloud environment, yet emulate the GOV, COM, and ORG “on-premises” in an IaaS cloud. One benefit of building in Azure was the ability to capture our final solution as PowerShell and JSON files, available for redeployment for any future research. Given the time limit of one year on the Azure Research Grant CITATION Mic17 \l 1033 [128], this provides the ability for other researcher to use this deployment and solution as a “starting point” for any additional capabilities and ideas. Using the processes captured CITATION Fit17 \l 1033 [129], we can redeploy these resources automatically using our resource manager templates and Azure PowerShell.This chapter complements the Build Guide, provided as an appendix to this work. The Build Guide provides a step-by-step deployment model of what we created here in the Azure and O365 environments. Solution Overview (Executive Summary)As captured in CITATION Gar17 \l 1033 [18], and leveraging the formative work in CITATION Placeholder1 \l 1033 [7] by Garcia and Chow, the deployment approach uses the following three phases: develop the architecture, develop federated identity solutions, and finally, build and assess. Here we provide a summary of the process captured in more detail in CITATION Gar181 \l 1033 [130]. Where important, we will call attention to configuration settings and design decisions. Develop the ArchitectureThe first phase is to develop the architecture of a hybrid cloud solution based on a first responder use case. We will compare the architecture against related research and models. At this point, an initial threat model will take form. Detailed components include:?Capture an initial operational disaster response scenario as the use case to demonstrate.?Create a minimum two-node, expandable architecture which includes a private cloud and community cloud (notionally, .gov, .com, and .org). ?Determine the minimum components in this simplified architecture required to represent the home “cloud” and the community cloud.?Capture the federated identity minimum components.?Identify the components of a threat model from which to expand the areas of development and research. Capture the threat vectors and develop the initial taxonomy or terms of reference.?Validate the above “in scope” and “out of scope” architectural components for the next phases of research.Operational Disaster Response ScenarioHere we settled on a wildfire disaster response with participation from notional GOV, COM, and ORG participants: , , and . These three will collaborate in our cloud response site to deliver water supplies to a required location. Proposed Build-to ArchitectureGiven the use of the Azure research workspace CITATION Mic17 \l 1033 [128] and an existing O365 E3 MSDN developer site, the below technical architecture demonstrates three unrelated “on-premises” domains built in Azure and one response site.Figure 7 SEQ Figure \* ARABIC \s 1 1 High level architecture for disaster response scenario.The intent is for the responding organizations, whom have not met prior to the event, to meet in the cloud at the response site. Minimum Initial Components for the ArchitectureTo validate the scenario, the parent GOV, COM, and ORG domain must have sufficient infrastructure to emulate an “at home” environment. Fortunately, each domain has an approach that is standards-based and maps to our model. These components include:Domain Controllers (primary and backup)Active Directory or other directory serviceDomain Name Services (DNS)Certificates (we used wildcard certificates per domain from DigiCert)User accountsA key decision point for the build was to implement a flat versus robust network. A robust network would have fault tolerance and redundancy to address load balancing and availability. Given the minimal impact on the system with only a few user accounts, the flat network allows simplicity and does not detract from the model. We did implement a primary and backup domain controller for domain stability. Federated Identity Minimum Components (initial)For simplicity in the Azure environment, we built each of the virtual machines on Windows Server 2016. Initial identity services include:DNS for each domainDNS for O365 environmentDomain ControllersUser accountsActive Directory Federation ServicesIdentity Providers (the GOV, COM, and ORG domains) Relying Party (the O365 community cloud)The community cloud in O365 included the existing domain hosted on an existing MSDN subscription. DNS services are provided by both Microsoft and . Administrative access is via while the Azure account access was via initial domain model (example for GOV below) is in the below figure. Figure 7 SEQ Figure \* ARABIC \s 1 2 GOV initial in scope build to architecture (infrastructure and identity).The initial federation architecture is also represented below.Figure 7 SEQ Figure \* ARABIC \s 1 3 GOV initial in scope build to architecture (infrastructure and identity).Initial Threat ModelThe current architecture has several seam and internal points which may present vulnerabilities to our existing solution. Throughout the build, we recursively identify and attempt to propose ways to mitigate the threat issues. The threat model we propose is not based on all cloud or all on-premises security issues, but rather with those pertaining specifically to the federated identity approach. Continuing with Khattak et al. CITATION Zub10 \l 1033 [126], we propose these threat model components:Identity theft: User credentials or identities in response networks risk compromise by typically attacks, such as phishing, which attackers can use to compromise or impersonate activities on the system.Misused identity information: Given we will propose identity federation via the use of identity providers and relying parties, these could be misused by those providers or by bad actors posing as those providers.Trust relationship vulnerabilities: Related to the above, the misuse of security tokens exchanged as part of the claims-based federated authentication would compromise our architecture. Develop Federated Identity SolutionsThe second phase is to develop a federated identity solution. The intent is to create a standards-based solution which may be available both on-premises and hopefully, with select cloud providers. The notional “connect policies” for the scenario will codify the processes through which federation will be possible. Here we will also further mature the threat model. Components include:?Refine the operational disaster response scenario, as required, to accurately allocate the federation solution to the proposed architecture.?Create the “home” private cloud/data center within Azure.?Create the community cloud site in O365. ?Allocate available standards-based federation solutions to the model.?Document the processes needed to securely connect and federate within the environment. ?Assess initial suitability against the original papers CITATION Placeholder1 \l 1033 [7], CITATION Gar17 \l 1033 [18].?Further refine the threat model and capture the component to assess.Refine the Disaster Response ScenarioThe three organizations responding to a Colorado wildfire will meet in the cloud using O365 Teams to collaborate on the delivery of needed water to a given location.Create the “home” private cloudAzure provided an excellent, script-based approach which allowed us to “build once” and “reuse many” times. We used identical build processes to instantiate the private clouds for GOV, COM, and ORG. While the Build Guide CITATION Gar181 \l 1033 [130] contains extensive detail and screen shots, the below is the overarching build approach.Access all required accounts and software (PowerShell, PowerShellGet, Azure PowerShell, AzureRM module, Azure AD Connect, DigiCert certificate utility, O365 licenses)Create resource groups (GOV, COM, ORG) in three separate Azure regions (this is to simulate distributed home datacenters and isolates resources both physically and virtually)Create Virtual Networks (VNETs) and subnetsConfigure load balancerCreate Network Security Groups (e.g., inbound ports for 443 and RDP)Create Primary and Backup Domain ControllersCreate DNS servicesCreate Active Directory services and initial responder user accountsBuild initial ADFS server (without federation services to cloud)Reserve Web Application Proxy (WAP) virtual machineInstall required certificatesConfigure domain name services (on-premises and with )Through this step within phase two, our intermediate architecture is reflected below.Figure 7 SEQ Figure \* ARABIC \s 1 4 On-premises domain architecture, GOV domain (pre-federation)Create the community cloudThe community cloud represents the disaster site for participants to meet for a specific event. The benefit of cloud provisioning is the low cost when not in use, and scalability when needed. A “skeleton” site of templates for events, complete with workflow and products, can be staged in the community cloud until the event occurs. Our build scope includes an “out-of-the-box” Microsoft O365 Teams CITATION Mic \l 1033 [131] site with full collaboration. Microsoft Teams combines workplace chat, conferencing, conversations, wikis, meetings, notes, and attachments. It also shows the availability of participators via presence. Given the use of an MSDN subscription and existing DNS provider, this process started somewhat convoluted but turned into an excellent example of rapid cloud provisioning. Given the cost of a new domain and reconfiguration required, the disaster site DNS remained . Creating the community cloud included:Configuring DNS services between and the administrative console at O365 service DNS settings at MX recordsOther mail servicesSIP / Skype servicesFederation pointers on ports 443 and 5061Configure licensing (as needed)Provide initial pointers to participating domainsgov-com-org-The initial organization configuration of the community cloud appears below.Figure 7 SEQ Figure \* ARABIC \s 1 5 Community Cloud organizational set up (pre-federation)Allocate federation solutionsThe core of our build work is in the federation settings. The below contribute to the steps and processes required for repeatability for this solution. The on-premises steps include:Build the ADFS Proxy Role (Web Application Proxy)Build VMs / serversInstall certificatesConfigure name resolutionConfigure network security groups (firewall rules)Configure WAPConfigure Azure AD Connect Configure ---Run Azure AD ConnectRun MSOL commands on federation servers to complete federationConvert-MsolDomainToFederated -DomainName gov-Verify federation configuration and SSOAt the end of this step, we verify the configuration of the servers and services.The community cloud steps include adding the domain names (as seen in the configuration for O365), and optionally, allocating user licenses as required.Document the Processes to Connect and Federate The processes required for the responding organization, specifically FEMA, Walmart, and Red Cross in our scenario, include:Identify responding organizationsIdentify disaster site (community cloud)Each organization capture subset of responders in identity container (e.g. Active Directory Group)Each organization enable ADFS or equivalent with internet-facing WAPRun Azure AD Connect for internal infrastructurePoint Azure AD Connect federation to the disaster siteRun federationRun synchronization between organization and disaster siteAssign licenses as needed for SaaS modelAssign permissions as needed within disaster site (e.g. owner, contributor)Operate.Assess Initial Suitability [92], [93]With additional detail in the Build Guide, we assess the suitability against our earlier model. Figure 7 SEQ Figure \* ARABIC \s 1 6 This solution mapped to the NIST cloud model. CITATION PMe11 \l 1033 [86]Alignment with cloud model. Our results reflect a hybrid cloud approach to information sharing during disaster response. Specifically, we leverage both a private and community cloud (“hybrid” by definition), which provides a SaaS (O365) solution for responders, showing the essential characteristics of broad network access, on-demand self-service, rapid elasticity, resource pooling, and measured service. The above figure is the NIST model from Mell and Grance. CITATION PMe11 \l 1033 [86] It should be noted that our “on-premises” build was also in an Azure IaaS solution, but this represents any “come as you are” service from the responding organizations (e.g., parent datacenter, private cloud, mobile datacenter, etc.)“Come as you are.” Each responding organization arrives with intrinsic equipment (mobile or computing as the Teams application is available on PC, IOS, Android, and other platforms.) Additionally, there is no change to parent identity or login credentials. Key coordination between the authoritative lead agency and the supporting teams is required, but this is the essential step to confirm both verifiable identity and a trusted federation model.Alignment with de facto standards. The solution allows an approach which models current distributed identity and authentication standards, leveraging of existing parent identity, limited to no forward identity architecture additions, and immediate inter- and intra-organizational collaboration.Resilient. Given the O365 infrastructure model with internal and geographical redundancy, the cloud solution maintains high SLAs and availability. This can be augmented by responding team infrastructure locally for mission critical information and edge computing ideas addressed in the literature survey.Distributed vs Centralized Model. Related to the de facto architecture, the distributed model is ideal for disaster response as it limits any given single point of failure. The solution here reflects this distributed model. Standards-based. No new protocols or federation approaches were developed in this work, and we maximize use of SAML 2.0 and OAuth. The use of the open-architecture Azure AD enables the below standards-based providers in our scenario. Figure 7 SEQ Figure \* ARABIC \s 1 7 Standards-based architecture for federation (SAML 2.0, OAuth). CITATION Bil171 \l 1033 [132]Elasticity: In today’s resource-constrained environment, no one organization can afford the infrastructure to host what “might” be a disaster response on the scale of, say, Hurricane Katrina. The Azure and O365 hybrid cloud solution provides the scaling ability of the responding organizations to scale 2x, 10x, and even 100x as needed given the global capacity of cloud providers. During non-threatening times (steady state), the solution templates for hurricane response, wildfire, etc. can rest unused on the infrastructure until the time needed. This is a revolutionary approach to capacity management in disaster response and is in stark contrast to the de facto model today. Verifiable Identity and Trust: Unlike consumer models and today’s approach where many responders use Gmail, Yahoo, Hotmail, and other similar, non-verifiable identities, this trusted model reaches back to the IDP to guarantee verifiable identity CITATION Mey131 \l 1033 [6]. As an example, each notional organization we chose, FEMA, Walmart, and Red Cross, have on-premises solutions and approaches to verifying the identities of employees as they create accounts (ID card, proof of citizenship, etc.). This verifiable identity increases inter-organizational trust as the response takes place and minimizes the time wasted in the current approach of validating and creating new identities as responders arrive. Security: Our approach provided security across several perspectives. The ability to provision parent day-to-day identity early and rapidly from the host sites (IDPs) minimized creating new identities in a chaotic environment. The accreditation standards inherent in the cloud model (e.g., FEDRAMP for Government Community Cloud Azure and O365) brings along security from a compliance and auditing perspective. Bad Internal Actor Elimination. Federation brings a powerful authentication and authorization perspective as well. A host disaster coordinating organization cannot possibly maintain status of all responders from multiple organizations. Should an individual be terminated and no longer authorized by the parent organization, federation implies that the access call from the RP to the IDP would fail given the SAML handshake between organizations. As a result, there is a high level of assurance that a terminated “bad actor” would not be able to access the solution, contrasted with today’s model of multiple accounts and identities. Refine the Threat Model The threat model related to federated identity in a hybrid cloud in REF _Ref509153580 \r \h 7.2.1.5 is still valid. The federation process, and the risk to authentication, authorization, and access control remain apparent. One area we plan to focus on includes the ability of bad actors to intercept and replay the claims tokens in the federation scenario. A real-world incident includes the use of both shared computers and kiosks in disaster response. Another scenario is a dropped phone or device. Later, we test the token replay attack against the architecture and assess suitability.A key finding here relates to proactive sharing of attempted access and malicious activity. It should be noted that while federation prohibits unauthorized and unauthenticated users, there is no intrinsic, proactive sharing of audit trails from the Relying Party (RP) to the IDP. This should be a finding as well and an area for consideration.Build and AssessThe last phase is to build and assess. Most of the “build” is done by this point, so our assessment is in line with the above findings (“Assess Initial Suitability”). Additionally, we captured the Azure Resource Group code in JSON and PowerShell to enable future builds, given the expiration of our research grant in 2018. Token Replay AttackA common attack in web-based browsing and applications is the token replay attack. Given the use of SAML 2.0 and other federation protocols, the passing of session tokens leaves the potential for token theft and reuse. In a replay attack, the attacker steals and replays the packets related to the authentication session. Our first build included an ADFS on-premises architecture with a WID database for identity stores. The demonstrated Token Replay Attack CITATION Gar182 \l 1033 [133] reveals that WID does not provide token replay detection. CITATION Mic16 \l 1033 [134] notes that in the choice between WID and SQL as the database, SQL is recommended. SQL provides feature support of SAML artifact resolution and SAML/WS-Federation token replay detection. For this reason, the design decision is to use SQL as the ADFS database. RecommendationsHere we provide the following recommendations for this research.ArchitectureThe final architecture captured in REF _Ref509152957 \r \h 7.2 includes hybrid cloud with distributed IDPs at each responding organization (private cloud or datacenter), and one or more disaster response sites in a community cloud (RPs). Federation PracticesThe federation practices captured in REF _Ref509153036 \r \h 7.2.2 include the key identity overlay components to our hybrid cloud architecture. SecurityKey security components related to hybrid cloud federated identity solution include:Verifiable identity: Each organization provides suitable guarantees for lifecycle management of IDAM for each responder, to include revocation and suspension. The responding organizations captured in our scenario do this today.Shared revocation and suspension logs: To prevent malicious use of credentials, periodic sharing of revocations and suspensions should be considered. Standards-based federation: Each participating organization deploys federation standards discussed in REF _Ref509153307 \r \h 5.3 and REF _Ref509152957 \r \h 7.2Token replay detection-enabled services (e.g., SQL database for ADFS services when used.)ConclusionHere we complete the three-phased architecture build of our hybrid cloud federated identity solution supporting our first responder scenario. Using on-premises representations of GOV, COM, and ORG participants (built in our Azure environment) and a single disaster response site (built in our MSDN O365 environment), we demonstrate how responders from disparate organizations can quickly meet and collaborate, thus accelerating disaster response coordination. CHAPTER 8Conclusion and Future Research In this research, we propose and demonstrate the first hybrid cloud federated identity solution which accelerates secure disaster response information sharing capabilities of disparate responders. The “come as you are” desired approach is met, and simplicity coupled with mission success are the outcomes.Known Concerns and Solutions A key premise of our research is security. While we have refined the threat model to address our specific architecture and emphasized the federated identity aspects, there are clearly a broader list of threats as is prevalent in networked systems. We chose to refine our threat model and approach to the specific contribution of this research, namely that of federated identity in a hybrid cloud environment.An additional consolation is that the government community cloud proposed must meet the stringent process of FedRAMP certification. From research, we believe the model of cloud computing proposed benefits from this existing rigorous approach.Federation is as strong as its weakest link. The C2 of the ICS must ensure vetting of responding and federating organizations a priori to ensure security of the architecture. In the researcher’s opinion, this does not detract from the expedience demonstrated in the solution as most responding organizations we can catalog are part of the network which currently participates in table top, wargames, and other exercises and simulations. This adoption of policy would be just another component of the national ICS. Evaluation of Success CriteriaFrom our original proposal CITATION Placeholder1 \l 1033 [7] and initial architectural and procedural approach CITATION Gar17 \l 1033 [18], our findings here address the success criteria of suitability and security. These include:Alignment with the NIST cloud definitionAlignment with de facto standards in disaster responseResilienceDistributed versus centralized architectureStandards-based versus proprietaryElasticity (scale plus practical cost savings)Verifiable identityTrusted architectural and federation modelSecurity with “bad actor” marginalization/eliminationContributionsHere we demonstrate the first hybrid cloud federated identity solution which accelerates the disaster response information sharing capability of disparate groups using the requested “come as you are” approached. Measured against suitability proposals, this work contributes the following: Research linking disaster response and cloud computingWe demonstrate that emerging cloud solution will enhance disaster response. Research linking disaster response and federated identityWe reveal how foundational verifiable identity and a federation approach enhance response success and trust. Establish federated identity hybrid cloud architectureHere we “stretch” the identity architecture across the private and community (hybrid) cloud construct to enhance “ability to connect” quickly.Capture processes to connect in a “come as you are” approachWe provide policy change to make the solution successful vis-à-vis providing the “how to connect” approach for each organization.Address process and policy issues for successful deploymentWe highlight first federated identity hybrid cloud policy which will augment or replace legacy policy.Future ResearchDuring the research, there were many areas which highlighted the demand for innovation for information sharing in disaster response. Below are a few areas which lend themselves to enhancing the speed and resilience of establishing disaster response solutions which leverage the results in this research. Narumoto et. al CITATION Nar17 \l 1033 [135] discuss planning factors for developing solutions for autoscaling. Edge Computing and Hybrid CloudDisaster response, especially for no-notice or short-notice disasters, require cost-effective solutions which quickly scale to the order of magnitude needed for the situation. Narumoto et. al CITATION Nar17 \l 1033 [135] discuss planning factors for developing solutions for autoscaling, as does the Amazon CITATION Ama18 \l 1033 [136]. Leveraging this testbed to include a cloud-of-clouds approach would be an inclusive way of extending the research environment. Mobile Application DevelopmentGiven a multi-cloud, stable federated identity framework, the ability to extend development to devices and applications is a key enabler. The platform for the disaster response scenario could serve as a testbed for mobility experimentation. IoT and Smart CitiesUniversity campuses and connected infrastructure can potentially become a point of integration with this work. Testing IoT and smart city concepts with this platform would provide researchers the ability to assess ideas on a low-cost cloud platform.PolicyEvolving technology calls for changing policies. As discussed in this research often the policy lag marks doom for technological innovation. This environment would enable public policy planners to assess technology impact on current and future policy. Critical Infrastructure ProtectionDeveloping attack concepts to this environment could help researchers learn how the changing cloud platform is vulnerable to attack, especially in this lightweight disaster response scenario. Interagency CollaborationPublic-academic partnerships are very possible via use of this research environment. Potential partners include DHS, FEMA, military, state, and local governments and responders. NGOs and Community-Based Authentication and AuthorizationA challenge to disaster response includes participation by various NGOs which may or may not register with the lead agency upon arrival. With the best intentions, sometimes NGOs provide additional disruption in their desire to help. Additionally, there are some “pop up” not validated organizations claiming to be NGOs which have nefarious goals to use the disaster situation for personal gain. Our solution could be leveraged to address the inclusion or exclusion of organizations and provide a platform for responders to validate their authenticity.As proposed in CITATION Alk15 \l 1033 [137], a community-based authentication and authorization (CAA) approach could be effective in validating NGOs, mobile users, citizens, and responders in our scenario. CAA enables users to pre-designate community group of members to authenticate one another. The example includes a new user requesting authentication to a server, and that server sends an SMS to a community group, and that group then requests them to authenticate that user and approve access to shared resources. The applicability of this solution to edge computing is apparent in a potential loss of long-haul communications (e.g., cloud) in our scenario which would prevent initial authentication and authorization.ConclusionAs disaster response and humanitarian missions continue to challenge responders and citizens alike, adopting technological and policy changes as proposed here will enhance public-private partnerships in pursuing mutual success. Mitigation of loss of lives and property destruction will be key outcomes, and accelerating return to normal, steady state operations can become the norm, not the exception. By adopting federated identity approaches in a hybrid cloud environment, the potential to support optimized disaster response is within reach with existing technologies, processes, and organizations. Bibliography BIBLIOGRAPHY [1] Federal Emergency Management Agency, "National Response Framework (NRF)," 2013. [Online]. Available: . [Accessed 15 September 2014].[2] R. I. Desourdis and J. M. Contestabile , "Information Sharing for Situational Understanding and Command Coordination in Emergency Management and Disaster Response," in 2011 IEEE International Conference on Technologies for Homeland Security (HST), Waltham, MA, 2011. [3] P. Mell and T. Grance, "The NIST Definition of Cloud Computing," National Institute of Standards and Technology, Gaithersburg, 2011.[4] I. Thomas W. Connell, "Managed Attributes, not Standards, Lead to Interoperability," in 2011 IEEE International Conference on Technologies for Homeland Security (HST), Waltham, MA, 2011. [5] W. Starnes, "Applying and Extending SCAP to Deliver the Trusted Cloud," IAnewslaetter, vol. 14, no. 4, pp. 26-31, Fall 2011. [6] D. W. Meyerrose, "Goodbye Cybersecurity-Hello Verifiable Trust," On the Front Lines Magazine, vol. 5, no. 3, p. 12, April 2013. [7] R. Garcia and E. Chow, "Identity Considerations for Public Sector Hybrid Cloud Computing Solutions," in 2015 International Conference on Computer Communication and Informatics, Coimbatore, 2015. [8] G. Godavari and E. Chow, "Secure Information Sharing Using Attribute Certificates and Role Based Access Control," in International Conference on Security and Management, 2005. [9] U. Hoffman, "Dynamic Evacuation Architecture Using Context-Aware Policy Management," in International Journal of Computer Science and Applications, 2009. [10] M. Landahl, "First responder identity management policy options for improved terrorism incident response," Naval Postgraduate School, Monterey, 2006.[11] E. Bertino, "Privacy-preserving Digital Identity Management for Cloud Computing," Bulletin of the IEEE Computer Society Technical Committee on Data Engineering, 2009. [12] E. Schwartz and K. Ferrell, "The US Military and NGOs: Breaking Down the Barriers," US Army War College, Carlisle, 2007.[13] W. Jansen and T. Grance, "NIST Special Publication 800-144: Guidelines on Security and Privacy in Public Cloud Computing," 2011.[14] V. Kundra, "Federal Cloud Computing Strategy," 8 February 2011. [Online]. Available: . [Accessed 10 October 2014].[15] FEDRAMP, "FedRAMP," Federal Risk and Authorization Management Program, 2016. [Online]. Available: .[16] Department of Justice, "California DoJ and Microsoft Adjudication Agreement for Government Community Cloud," 2013.[17] G. Sleter, "San Francisco's Migration of 29,000 Employees to the Cloud is Underway," Government Technology, 2014. [18] R. Garcia, "Federated identity hybrid cloud security considerations supporting first responders," in 2017 IEEE Conference on Dependable and Secure Computing, Taipei, 2017. [19] R. E. Garcia, "NIST Cybersecurity Framework," Computer Science Department, Colorado Springs, 2013.[20] N. Staff, Interviewee, Interview with NORTHCOM Staff. [Interview]. 16 September 2014.[21] USNORTHCOM, "USNORTHCOM lends support for wildfires," 21 July 2017. [Online]. Available: .[22] M. Monti, Interviewee, Interview with Operation Unified Assitance Combined Task Force J6. [Interview]. 15 July 2005.[23] L. Yan, C. Rong and G. Zhao, "Strengthen Cloud Computing Security with Federal Identity Management Using Hierarchical Identity-Based Cryptography," in Cloud Computing, 2009. [24] B. Prasanalakshmi and A. Kannammal, "Secure Credential Federation for Hybrid Cloud Environment with SAML Enabled Multifactor Authentication using Biometrics," International Journal of Computer Applications, vol. 53, no. 18, September 2012. [25] A. Celesti, F. Tusa, M. Villari and A. Puliafito, "Security and Cloud Computing: InterCloud Identity Management Infrastructure," in 2010 Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises , 2010. [26] K. Khan and Q. Malluhi, "Establishing trust in cloud computing," IT Professional, 2010. [27] S. Sengupta, V. Kaulgud and V. S. Sharma, "Cloud Computing Security - Trends and Research Directions," in 2011 IEEE World Congress on Services, 2011. [28] M. Chuan-Hao, "National Authentication Framework Implementation Study," Monterey, CA, 2009.[29] R. Dourandish, N. Zumel and M. Manno , "Automated Military-Civilian Information Sharing," in IEEE Military Communications Conference, 2006, Washington, DC, 2006. [30] D. Zissis and D. Lekkas, "Addressing cloud computing security issues," 2012 Future Generation Computing Systems, vol. 28, pp. 583-592, 2012. [31] G. Dreo, M. Golling, W. Hommel and F. Tietze, "ICEMAN: An Architecture for Secure Federated Inter-Cloud Identity Management," in IFIP/IEEE IM2013 Workshop: 5th International Workshop on Management of the Future Internet (ManFI), 2013. [32] M. Zambrano, I. Perez, F. Carvajal, M. Esteve and C. Palau, "Command and Control Information Systems Applied to Large Forest Fires Response," IEEE Latin America Transactions, vol. 15, no. 9, pp. 1735-1741, September 2017. [33] S. Wozniak, M. Rossberg and G. Schaefer, "Towards Trustworthy Mobile Social Networking Services for Disaster Response," in Third International Workshop on Pervasive Networks for Emergency Management, San Diego, 2013. [34] W. Shi, J. Cao, Q. Zhang, Y. Li and L. Xu, "Edge Computing: Vision and Challenges," IEEE Internet of Things Journal, vol. 3, no. 5, pp. 637-646, 2009 November 2016. [35] N. Mir and S. Loreto, "Cloud and Edge Computing," IEEE Communications Standards Magazing, p. 40, December 2017. [36] S. Mittal, N. Negi and R. Chauhan, "Integration of edge computing with cloud computing," in 2017 International Conference on Emerging Trends in Computing and Communication Technologies (ICETCCT), 2017. [37] C. Mouradian, D. Naboulsi, S. Yangui and R. H. Glitho, "A Comprehensive Survey on Fog Computing: State-of-the-art and Research Challenges," IEEE Communications Surveys & Tutorials, vol. PP, no. 99, p. 1, 2017. [38] H. Chang, A. Hari, S. Mukherjee and T. Lakshman, "Bringing the Cloud to the Edge," in 2014 IEEE INFOCOM Workshop on Mobile Cloud Computing, 2014. [39] C. Alex and A. Vijaychandra, "Autonomous Cloud Based Drone system for," in 2016 International Conference on Robotics and Automation for Humanitarian Applications (RAHA), 2016. [40] A. Goel, G. G. M. Bhushan and N. Nirwal, "Identity Management in Hybrid Cloud," in 2015 International Conference on Green Computing and Internet of Things (ICGCloT), 2015. [41] N. Abwnawar, H. Janicke, R. Smith and A. Lasebae, "Towards data privacy in heterogeneous cloud environments: an extension to the SANTA policy language," in 2017 Second International Conference on Fog and Mobile Edge Computing (FMEC), 2017. [42] S. N. Shirazi, A. Gouglidis, A. Farshad and D. Hutchison, "The Extended Cloud: Review and Analysis of Mobile Edge Computing and Fog From a Security and Resilience Perspective," IEEE Journal on Selected Areas in Communications, vol. 35, no. 11, pp. 2586-2595, November 2017. [43] C. Parera, Y. Qin, J. Estrella, S. Reiff-Marganiec and A. Vasilakos, "Fog Computing for Sustainable Smart Cities: A Survey," ACM Computing Surveys, vol. 50, no. 3, pp. 32:1-32:43, June 2017. [44] W. Hou, Z. Ning and L. Guo, "Green Survivable Collaboration Edge Computing in Smart Cities," IEEE Transactions on Industrial Informatics, 2018. [45] J. Skirelis and D. Navakauskas, "Edge Computing in IoT: Preliminary Results on," in 2017 5th IEEE Workshop on Advances in Information, Electronic and Electrical Engineering (AIEEE), 2017. [46] Q. Zhang, Q. Zhang, W. Shi and H. Zhong, "Firework: Data Processing and Shareing for Hybrid Clouid-Edge Analytics," Transactions on Parallel and Distributed Systems, 2018. [47] T. Zhao, S. Zhou, X. Guo and Z. Niu, "Tasks Scheduling and Resource Allocation in Heterogeneous Cloud for Delay-bounded Mobile Edge Computing," in IEEE ICC 2017 SAC Symposium Cloud Communications and Networking Track, 2017. [48] L. Guerdan, O. Apperson and a. P. Calyam, "Augmented Resource Allocation Framework for Disaster Response Coordination in Mobile Cloud Environments," in 2017 5th IEEE International Conference on Mobile Cloud Computing, Services, and Engineering, 2017. [49] J. Zhang, WeiweiXia, Z. Cheng, Q. Zou, B. Huang, F. Shen, F. Yan and L. Shen, "An evolutionary game for joint wireless and cloud resource allocation in mobile edge computing," in 2017 9th International Conference on Wireless Communications and Signal Processing (WCSP), 2017. [50] X. Ma, S. Zhang, P. Yang, N. Zhang, C. Lin and X. Shen, "Cost-Efficient Resource Provisioning in Cloud Assisted Mobil Edge Computing," in GLOBECOM 2017 - 2017 IEEE Global Communications Conference, 2017. [51] K. Kaur, S. Garg, G. S. Aujla, N. Kumar, J. J. P. C. Rodrigues and M. Guizani, "Edge Computing in the Industrial Internet Things Environment: Software-Defined-Networks-Based Edge-Cloud Interplay," IEEE Communications Magazine, pp. 44-51, February 2018. [52] T. Subramanya, L. Goratti, S. N. Khan, E. Kafetzakis, I. Giannoulakis and R. Riggio, "A Practical Architecture for Mobile Edge," in 2017 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN), 2017. [53] A. Peleg, "Multi-cloud, Fog, Edge & Hybrid Computing – What’s the Difference?," 2017. [Online]. Available: . [Accessed 7 December 2017].[54] A. Schirrmann, "Simulation of Performance-based Services in Disaster Response Operations," in Proceedings of the 2017 Winter Simulation Conference, 2017. [55] G. Premsankar, M. D. Francesco and T. Taleb, "Edge Computing for the Internet of Things: A Case Study," IEEE Internet of Things Journal, pp. 1-10, 2018. [56] K. Wang, H. Yin, W. Quan and G. Min, "Enabling Collaborative Edge Computing for Software Defined Vehicular Networks," IEEE Network, pp. 1-6, 2018. [57] M. Marjanovis, A. Antonic and I. P. Zarko, "Edge Computing Architecture for Mobile Crowdsensing," IEEE Access, pp. 1-13, 2018. [58] J. Z. Moghaddam, M. Usmany and F. Granelliy, "A Device-to-Device Communication based Disaster Response Network," IEEE Transactions on Cognitive Communications and Networking, 2018. [59] Department of Homeland Security, "Homeland Security Presidential Directive 5 (HSPD-5)," 28 February 2003. [Online]. Available: .[60] Department of Homeland Security, "National Response Framework," May 2013. [Online]. Available: .[61] National Interagency Fire Center, "National Interagency Fire Center," [Online]. Available: .[62] National Wildfire Coordinating Group, "National Wildfire Coordinating Group," [Online]. Available: .[63] NWCG, "ICS Forms," [Online]. Available: .[64] FEMA, "National Incident Management System (NIMS)," [Online]. Available: . [Accessed 15 September 2014].[65] President of the United States, "Homeland Security Presidential Directive-5 (HSPD-5)," 2003. [Online]. Available: . [Accessed 16 September 2014].[66] FEMA, "Incident Command System Resources," [Online]. Available: .[67] FEMA, "NIMS ICS Forms Bookley," September 2010. [Online]. Available: .[68] FEMA, "Incident Command System Resources," 15 November 2017. [Online]. Available: .[69] FEMA, "Action Requst Form FF 90-136," 20 May 2008. [Online]. Available: .[70] FEMA, "Resource Request Form (RRF) FEMA Form 010-0-7," [Online]. Available: .[71] FEMA, "Mission Assignment and FEMA form 010-0-8," [Online]. Available: .[72] Department of Defense (DoD), "Joint Publication 3-29 Foreign Humanitarian Assistance," US Government, Washington DC, 2014.[73] FEMA, "Prescripted Mission Assignments Fact Sheet," [Online]. Available: . [Accessed 15 September 2014].[74] FEMA, "Homeland Security Information Network (HSIN)," FEMA, [Online]. Available: .[75] Intermedix , "Intermedix WebEOC," [Online]. Available: .[76] FEMA, "DHS AppAuth February 2017 Update," 15 February 2017. [Online]. Available: .[77] M. Dana, Interviewee, Interview with BGen Mike Dana, NORTHCOM J4. [Interview]. 12 April 2010.[78] P. K. MIlligan, "PACOM Disaster Response Lessons Trends 1991-2013," US Government, Honolulu, 2014.[79] G. Cecchine, F. Morgan, M. Wermuth, T. Jackson, A. G. Schaefer and M. Stafford, "The US Military Response to the 2010 Haiti Earthquake," Rand Corporation, Santa Monica, 2013.[80] H. Nishiyama, K. Suto and H. Kuribayashi, "Cyber Physical Systems for Intelligent Disaster Response Networks: Conceptual Proposal and Field Experiment," IEEE Network, pp. 120-128, July/August 2017. [81] C. PHillips, T. Ting and S. Demurjian, "Information sharing and security in dynamic coalitions," SACMAT '02 Proceedings of the seventh ACM symposium on Access control models and technologies, pp. 87-96, 3-4 June 2002. [82] L. Palen and S. B. Liu, "Citizen communications in crisis: anticipating a future of ICT-supported public participation," in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, San Jose, 2007. [83] K. Lovejoy and G. Saxton, "Information, Community, and Action: How Nonprofit Organizations Use Social Media," Journal of Computer-Mediated Communication, vol. 17, no. 3, pp. 337-353, 1 April 2012. [84] Microsoft, "Microsoft Cloud for Government," Microsoft, 1 November 2015. [Online]. Available: . [Accessed 1 December 2015].[85] Amazon, "AWS in the Public Sector: Government, Education and Nonprofits," Amazon, 2015. [Online]. Available: . [Accessed 1 December 2015].[86] P. Mell and T. Grance, "The NIST Definition of Cloud Computing, NIST Special Publication 800-145," National Institute of Standards and Technology, Washington, DC, 2011.[87] D. M. Smith, "Hype Cycle for Cloud Computing, 2013," Gartner, Inc., Stamford, 2013.[88] D. M. Smith, "Hype Cycle for Cloud Computing, 2014," Gartner, Inc, Stamford, 2014.[89] A. Behl and K. Behl, "An Analysis of Cloud Computing Security Issues," in IEEE World Congress on Information and Communication Technologies 2012, 2012. [90] Trend Micro, "Best Practices for Security and Compliance with Amazon Web Services," April 2013. [Online]. Available: . [Accessed 15 December 2013].[91] J. W. Rittinghouse and J. F. Ransome, Cloud Computing: Implementation, Management, and Security, New York: Auerbach Publications, 2009. [92] PCI Security Standards Council, "PCI Data Security Standard (PCI DSS)," February 2013. [Online]. Available: .[93] S. Jontz, "Federal IG Access to Data Overcast by Rush to the Cloud," AFCEA SIGNAL, no. October 2014, pp. 39-41, October 2014. [94] R. Holgate and N. Cannon, "Get Ready for the Inflection Point in U.S. Federal Government Cloud Adoption," Gartner, Stamford, 2016.[95] V. Kundra, "25 Point Implementation Plan to Reform Federal Information Technology Management," Washington, DC, 2010.[96] P. M. Shanahan, "Accelerating Enterprise Cloud Adoption," Washington, DC, 2018.[97] A. Moscaritolo, "Report: Cyberattacks against the U.S. "rising sharply"," SC Magazine, 2009 November 2009. [98] NIST, "Risk Management Framework Overview," 2018.[99] Cloud Controls Matrix Working Group, "Cloud Security Alliance CCMWG," 1 September 2017. [Online]. Available: .[100] Cloud Security Alliance, "Cloiud Controls Matrix v3.0.1," 1 September 2017. [Online]. Available: .[101] International Organization for Standardization (ISO), "ISO/IEC 27000 family - information security management systems," ISO, [Online]. Available: .[102] International Organization for Standardization (ISO), "Standard ISO/IEC 27000:2009," 2010. [Online]. Available: .[103] FedRAMP, "FedRAMP Marketplace," 2018. [Online]. Available: .[104] D. W. Meyerrose, Interviewee, Interview with D.W. Meyerrose. [Interview]. 03 12 2013.[105] G. Kreizman, "Technology Overview for Federated Identity Management," Gartner, Inc, Stamford, CT, 2012.[106] D. Rountree, Federated Identity Primer, Boston: Elsevier, 2013. [107] International Telecommunication Union - Joint Coordination Activity for Identity Management (JCA-IdM), "Scope of identity management," 2014. [Online]. Available: .[108] N. Hastings and J. Franklin, "Considerations for Identity Management in Public Safety Mobile Networks NISTIR 8014," US Government, Washington DC, 2014.[109] Gartner, "Identity and Access Management (IAM)," Gartner, 2017. [Online]. Available: .[110] National Institute of Standards and Technology (NIST), "A Credential Reliability and Revocation Model for Federated Identities," US Government, Washington DC, 2012.[111] R. D. Vernon, "Cornell University IT Architecture Initiative," December 2001. [Online]. Available: . [Accessed 18 September 2014].[112] Defense Human Resource Activity, "DoD Common Access Card," [Online]. Available: . [Accessed 19 September 2014].[113] W. Rash, "Two-Factor Authentication Makes Your Scandalous Selfies Safe on iCloud - See more at: ," 17 September 2014. [Online]. Available: . [Accessed 19 September 2014].[114] M. E. Ruddy, "Understanding Modern Federation Trends and Their Influence on Identity and Access Architecture," Gartner, Inc, Stamford, CT, 2013.[115] D. Rountree, Federated Identity Primer, Waltham, MA: Elsevier, Inc, 2013, pp. 37-54.[116] OpenID Foundation, "OpenID Foundation," 2015. [Online]. Available: . [Accessed 12 December 2015].[117] Internet Engineering Task Force (IETF), "Request for Comments (RFC) 6749, The OAuth 2.0 Authorization Framework," IETF, 2012.[118] Organization for the Advancement of Structured Information Standards (OASIS) Committee, "SAML v2.0 Executive Overview," OASIS, 2005.[119] OASIS, "Web Services Security," OASIS, 2006.[120] Microsoft Corporation, "Windows Identity Foundation," Microsoft Corporation, Redmond.[121] E. Maler and D. Reed, "The Venn of Identity," IEEE Security and Privacy, pp. 16-23, 2008. [122] G. Kreizman and A. Singh, "Magic Quadrant for Access Management Worldwide," 7 June 2017. [Online]. Available: .[123] InCommon - Internet2, "Internet2 Industry Program - Trust and Identity Solution Providers," 2018. [Online]. Available: Internet2 Industry Program - Trust and Identity Solution Providers.[124] J. C. Perez, "Red Crdoss offers O365 to it units worldwide to improve communications," ComputerWorld, 25 February 2013. [Online]. Available: .[125] American Red Cross, "Red Cross Governance Report 2017," Red Cross, 2017. [Online]. Available: images/MEDIA_CustomProductCatalog/m4240145_BOGGovernanceReport.pdf.[126] Z. A. Khattak, S. Suziah, A. Manan and lamalul-Lail, "A Study on Threat Model for Federated Identities in Federated Identity Management System," in 2010 International Symposium in Information Technology (ITSim), Kuala Lumpur, 2010. [127] M. Warren, S. Leitch and I. Rosewall, "Attack Vectors Against Social Networking Systems: the Facebook Example," in Proceedings of the 9th Australian Information Security Management Conference, Perth, 2011. [128] Microsoft Research, Azure Research Grant, Redmond, 2017. [129] T. FitzMacken and A. Jenks, "Deploy resources with Resource Manager templates and Azure PowerShell," Microsoft, 6 December 2017. [Online]. Available: .[130] R. Garcia, "Hybrid Cloud Federated Identity Architecture Supporting Mission Critical First Responders: Build Guide," Colorado Springs, 2018.[131] Microsoft, "Microsoft Teams: Hub for teamwork in O365," [Online]. Available: .[132] B. Mathers and M. Tillman, "Azure AD federation compatibility list," Microsoft, 8 November 2017. [Online]. Available: compatibility.[133] R. Garcia, Director, Token Replay Attack. [Film]. Colorado Springs.2018. [134] Microsoft, "The Role of the ADFS Configuration Database," 31 August 2016. [Online]. Available: (v=ws.11).[135] M. Narumoto, Y. Batura, C. Bennage, M. Wasson and P. Wood, "Autoscaling," Microsoft, 17 May 2017. [Online]. Available: . [Accessed 15 February 2018].[136] Amazon Web Services, "Getting Started with Amazon EC2 Auto Scaling," [Online]. Available: . [Accessed 15 February 2018].[137] K. H. Alkhattabi, "On Community Based Authentication Factor," 2015.Appendix A – Federated Identity Hybrid Cloud Build GuideThis appendix is included as a separate file. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download