Secure Cloud Business Applications (SCuBA) Technical Reference

TLP:WHITE

Secure Cloud Business Applications (SCuBA)

Technical Reference Architecture (TRA)

DISCLAIMER: This document is marked TLP:WHITE. Disclosure is not limited. Sources may use TLP:WHITE when information carries

minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard

copyright rules, TLP:WHITE information may be distributed without restriction. For more information on the Traffic Light Protocol, see

http://www.cisa.gov/tlp/.

TLP:WHITE

Secure Cloud Business

Applications (SCuBA)

Technical Reference

Architecture (TRA)

Request for Comment Draft

Publication: April 2022

        TLP:WHITE 
Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA) 
 
 
 
      TLP:WHITE 
Contents 
Introduction...................................................................................................................... 1 
1 Background ......................................................................................................................... 1 
2 Purpose ............................................................................................................................... 1 
3 Scope................................................................................................................................... 2 
Development .................................................................................................................... 2 
Definition of Cloud Business Applications ......................................................................... 3 
Cloud Security Guidance .................................................................................................. 4 
1 CISA Cloud Security Guidance ........................................................................................... 4 
2 Federal Cloud Security Guidance ...................................................................................... 6 
Threats to Cloud Business Applications ............................................................................ 6 
Securing Cloud Business Applications .............................................................................. 6 
1 Identity, Credential, and Access Management ................................................................. 7 
2 Secure Cloud Access from Any Location ........................................................................... 9 
3 External Email Protections ............................................................................................... 10 
4 Protective Domain Name System .................................................................................... 11 
5 Endpoint Security Services .............................................................................................. 12 
5.1 Desktop Endpoint Security .................................................................................... 12 
5.2 Mobile Endpoint Security ...................................................................................... 12 
6 Application Security Configuration .................................................................................. 12 
6.1 Data Sharing and Exfiltration Protection ............................................................. 13 
7 Cyber Visibility and the eVRF Analytical Framework ...................................................... 13 
8 Telemetry Generation and Processing ............................................................................ 14 
8.1 Logging ................................................................................................................... 14 
8.2 Monitoring .............................................................................................................. 15 
8.3 Auditing ................................................................................................................... 15 
8.4 Alerting.................................................................................................................... 15 
8.5 Threat Detection .................................................................................................... 15 
9 Shared Responsibility Model ........................................................................................... 16 
9.1 Protective Security Controls and Services ........................................................... 16 
9.2 Visibility, Detection, and Response ...................................................................... 16 
References ..................................................................................................................... 18 
Appendix A. Glossary .......................................................................................................... 20 
Appendix B. Abbreviations .................................................................................................. 22 

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | iii TLP:WHITE

Figures

Figure 1-1. SCuBA System View .................................................................................................... 2

Figure 2-1. SCuBA Iterative Approach .......................................................................................... 3

Figure 3-1. Cloud Business Capabilities ....................................................................................... 4

Figure 6-1. SCuBA Security and Visibility View ............................................................................. 7

Figure 6-2. ICAM Practice Areas and Supporting Elements [12] ................................................ 8

Figure 6-3. SCA Concept .............................................................................................................. 10

Figure 6-4. External Email Flow................................................................................................... 11

Figure 6-5. eVRF Workflow .......................................................................................................... 13

Figure 6-6. SCuBA Telemetry ...................................................................................................... 14

Figure 6-7. Shared Responsibility Model ................................................................................... 16

Tables

Table 6-1. Security and Visibility Mapping to Sections ................................................................ 7

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 1 TLP:WHITE

1. Introduction 1

1.1 Background 2

The Cybersecurity and Infrastructure Security Agency (CISA) leads the national effort to understand, manage, 3

and reduce cyber risks, including by serving as the operational lead for Federal Civilian Executive Branch (FCEB) 4

cybersecurity by providing cybersecurity tools, incident response services, and assessment capabilities. Recent 5

cyberattacks provide ample evidence that the FCEB information technology (IT) enterprise requires continued 6

focused efforts to protect against sophisticated attacks by nation-state actors. 7

CISA established the Secure Cloud Business Applications (SCuBA) project per its authorities granted in the 8

American Rescue Plan Act of 2021 and the FY21 National Defense Authorization Act, P.L. 116-283. [1] [2] 9

Under the SCuBA project, CISA will establish and configure environments for Microsoft 365 (M365) and Google 10

Workspace (GWS). CISA will design cybersecurity architectures for M365 and GWS services by leveraging vendor 11

native capacities as well as third-party solutions as necessary. Establishing the visibility of cloud service 12

offerings and standing up test environments to enable selection, configuration, and testing of security 13

capabilities affords CISA the opportunity to: (a) expand its cloud security expertise to benefit both government 14

and critical infrastructure partners; (b) expand utilization of available cloud security related data across existing 15

and planned security programs; (c) improve program requirements and services; (d) share the knowledge gained 16

and lessons learned with FCEB agencies; and (e) help secure cloud business application environments across 17

the federal enterprise. 18

The SCuBA project will address cybersecurity and visibility gaps in business applications hosted in the cloud and 19

provide guidance to secure FCEB implementations. These gaps impact each agency’s ability to manage cyber 20

risk for its IT enterprise and CISA’s ability to adequately understand and manage cyber risk for the federal 21

enterprise. The SCuBA project will provide architecture and security configurations that offer fundamental 22

protections for cloud business applications and give FCEB agencies and CISA the visibility necessary to identify 23

and detect adversarial activity in their cloud environments. 24

1.2 Purpose 25

The purpose of the SCuBA Technical Reference Architecture (TRA) is to provide context, standard views, and 26

terminology that incorporate and align all SCuBA efforts. The SCuBA TRA is product and vendor agnostic and is 27

consistent with other federal, DHS, and CISA reference architectures (RAs). The SCuBA TRA is based upon the 28

Cloud Security TRA published by CISA, the United States Digital Service, and the Federal Risk and Authorization 29

Management Program (FedRAMP). [3] Development of the SCuBA TRA will require interagency coordination and 30

consultation with the major Cloud Service Providers (CSPs). The SCuBA TRA should be used to inform product-31

specific RAs, implementation architectures, and configuration guidelines that will be developed by other SCuBA 32

efforts. 33

A secure cloud-based business application (e.g., M365 or GWS) deployment requires a combination of 34

application configuration, security services (provided natively with the application or by a third party), integration 35

with existing enterprise systems, and robust operational practices. When fully developed, the SCuBA TRA will 36

provide threat-based guidance to create a secure implementation architecture. 37

CISA will engage with FCEB agencies to facilitate data acquisition of cloud logs and telemetry for analysis and—38

when needed—facilitate incident response and threat-hunting activities. Simultaneously, CISA will consult with 39

cloud vendors to identify opportunities to develop and improve solutions that provide enhanced security and 40

support for cloud business applications used by FCEB agencies. Cloud vendors occupy a unique vantage point in 41

the SCuBA TRA because they can identify trends and threat activities across sectors and service offerings. They 42

can also respond to threats that may be undetectable to their tenants, and they can update their offerings to 43

mitigate vulnerabilities and adversarial campaigns. CISA will work with agencies to address risks and maximize 44

benefits associated with their use of cloud services. 45

For SCuBA to be consistent with Office of Management and Budget (OMB) M-21-31, [4] agencies must work with 46

CISA to implement comprehensive logging and information-sharing capabilities. This coordination includes 47

agencies sharing telemetry and logs from their cloud business applications with CISA. Such information is 48

necessary for CISA to have the visibility and capacity to respond to evolving cloud threats and perform effective 49

monitoring, threat hunting, and incident response activities. In turn, CISA will share information that will allow 50

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 2 TLP:WHITE

agencies to collect, process, and analyze telemetry to fulfill their own internal security requirements, enhance 51

their visibility, and meet mission needs. 52

1.3 Scope 53

The scope of the SCuBA TRA is cloud business applications, delivered through a Software-as-a-Service (SaaS) 54

model to users, and the security services used to secure and monitor these applications. Figure 1-1 shows that 55

agencies are responsible for securely configuring their cloud business applications and collecting the associated 56

logs and telemetry to meet their security needs. 57

Figure 1-1. SCuBA System View 59

Agency Users: 60

• The scope of the SCuBA TRA includes connections from campus and internet sources. Agency strategies 61

for adopting Zero Trust (ZT) will define any changes or merging of campus and internet access. 62

• Agency user access is through agency endpoints. The management and security of the endpoints are 63

outside the scope of the SCuBA TRA. Additionally, Bring Your Own Device (BYOD) is not in scope of the 64

SCuBA TRA. 65

• Dedicated telephony devices, such as desktop phones using Voice over Internet Protocol or Time Division 66

Multiplex signaling, are not in scope of the SCuBA TRA. 67

External Users: 68

• External users include both trusted business partners and the public, who use the collaboration tools for 69

voice and video as well as document/content sharing. 70

Agency Subscribed Cloud Business Applications: 71

• The initial set of cloud business capabilities are scoped to M365 and GWS. These capabilities—which 72

currently include Productivity, Messaging, Content Management, Collaboration, and Voice—may expand in 73

the future. See Section 3 for more details on the scope of the cloud business capabilities. 74

2. Development 75

Initially, the SCuBA TRA comprises input from across CISA (e.g., National Cybersecurity Protection System 76

[NCPS], Vulnerability Management, and Continuous Diagnostics and Mitigation [CDM]), analysis and 77

identification of cloud security guidance, applicable supporting documents (Section 4), identification of 78

cybersecurity threats (Section 5), and necessary security capabilities to harden cloud business applications 79

(Section 6). 80

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 3 TLP:WHITE

SCuBA TRA updates will be based on lessons learned from other SCuBA efforts, such as product-specific testing, 81

configuration guidance, capabilities, and instance architectures. Updates will also be informed by input from 82

FCEB agencies; collaborations with CSPs and commercial organizations with mature cloud implementations; 83

and cloud threat assessments, testing, and input from cloud application and infrastructure security Subject 84

Matter Experts (SMEs). Figure 2-1 shows the SCuBA iterative approach. 85

Figure 2-1. SCuBA Iterative Approach 88

The SCuBA TRA supports CISA’s objective to keep pace with evolving technologies and capabilities. It 89

accomplishes this objective through the following iterative approach: 90

• Building on Existing Knowledge: CISA will build on current knowledge of CSP and SaaS offerings to provide 91

guidance based on understanding threats and related efforts. CISA will collaborate with the CSPs to 92

improve the SaaS offerings and how these interface with security services. 93

• CISA Cloud Security and SCuBA Baselines: CISA will first gather and assess feedback and lessons learned 94

from implementing within its own divisions, then it will deploy baselines in response to increasingly 95

complex mission needs. Applying SCuBA security solutions to a wide range of agencies will require iterating 96

on existing technologies and testing new capabilities. 97

• Enabling a Feedback Loop: As agencies deploy cloud solutions to meet mission needs, threats evolve to 98

leverage new tactics, techniques, and procedures (TTPs), and SaaS offerings change to reflect market 99

demands. A feedback loop is required to continue refinement of engineering solutions and improved 100

guidance on configuring SaaS offerings. 101

3. Definition of Cloud Business Applications 102

For the initial version of the SCuBA TRA, cloud business applications are defined as including the business 103

capabilities shown in Figure 3-1. 104

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 4 TLP:WHITE

105

Figure 3-1. Cloud Business Capabilities 106

Figure 3-1 groups the capabilities into categories using vendor-agnostic terms (Productivity, Messaging, etc.) 107

based on their functions. The examples under each category are not exhaustive, but they are representative of 108

the scope of the functions. Each category may have similar threats and security controls, and agencies can 109

assess the threats and security controls necessary to protect their enterprise and provide CISA the required 110

visibility. 111

The categories are: 112

• Productivity: Capabilities that allow users to perform business analytics and produce documents, graphs, 113

spreadsheets, presentations, diagrams, project schedules, and trackers. These capabilities produce 114

objects that are human readable and can be shared by Messaging or Content Management capabilities. 115

• Messaging: Capabilities focused on email, calendaring, and contact management. 116

• Content Management: Capabilities for website hosting, file storage and sharing, searching, and workflows. 117

• Collaboration: Capabilities that allow for real-time text, video, and desktop sharing. Productivity capabilities 118

can be used as an integrated function of the Collaboration capabilities. 119

• Voice: Capabilities focused on telephone-based functions, either initiated from a phone (mobile or wired) 120

or to connect to the Public Switched Telephone Network (PSTN). 121

4. Cloud Security Guidance 122

The following subsections list cloud security guidance documents that informed the development of the SCuBA 123

TRA. 124

4.1 CISA Cloud Security Guidance 125

CISA Cloud Security Technical Reference Architecture 126

The CISA Cloud Security TRA is a guide for agencies to adopt cloud technology for cloud deployment, adaptable 127

solutions, secure architecture, agile development, and ZT. [3] The guide discusses shared services, cloud 128

migration, and cloud security posture management. Various sections of the SCuBA TRA correspond to the CISA 129

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 5 TLP:WHITE

Cloud Security TRA including Identity, Credential, and Access Management (ICAM); Logging; Monitoring; and 130

Shared Services. 131

CISA NCPS Cloud Interface Reference Architecture Volumes 1 and 2 132

The NCPS Cloud Interface Reference Architecture is a two-volume set that explains how agencies can create 133

reporting patterns to describe their process for providing cloud-generated security information to CISA’s Cloud 134

Log Aggregation Warehouse. Volume 1 defines general reporting patterns. [5] Volume 2 is a catalog of reporting 135

patterns that are typical of how agencies can send telemetry from a single CSP or from multiple providers. [6] 136

Together these two documents describe multiple options for sharing cloud telemetry with CISA but do not define 137

specific requirements for what cloud telemetry is shared. The extensible Visibility Reference Framework (eVRF), 138

described later in this section, will be used as a framework for CISA to define telemetry requirements. 139

CISA Trusted Internet Connections 3.0 Core Guidance and Use Cases 140

The Trusted Internet Connections (TIC) 3.0 core guidance comprises the Program Guidebook, the Reference 141

Architecture, the Security Capabilities Catalog, the Use Case Handbook, and the Overlay Handbook. [7] 142

Together, these five documents can be used by agencies to develop and deploy modern architectures: 143

• The Program Guidebook outlines the TIC program and explains its history. 144

• The Reference Architecture defines the key technical concepts used to define TIC 3.0 architectures. 145

• The Security Capabilities Catalog is a library of security capabilities that will be used in TIC 3.0 use cases. 146

• The Use Case Handbook describes how agencies can create and use TIC use cases, in general. 147

• The Overlay Handbook defines how vendors can map their products and services to the TIC security 148

capabilities. 149

Additionally, TIC 3.0 use cases contain guidance on the secure implementation and/or configuration of specific 150

platforms, services, and environments. In accordance with OMB M-19-26, CISA has published the following use 151

cases: (1) Traditional TIC Use Case, (2) Branch Office Use Case, (3) Remote User Use Case, and (4) Cloud Use 152

Case (Draft). These publications contain specific guidance for agency IaaS, PaaS, SaaS, and EaaS deployments. 153

Each TIC use case contains a conceptual architecture, risk and deployment considerations, one or more security 154

pattern options, and security capability implementation guidance for a common agency computing scenario. 155

Agencies can combine use cases to modernize their enterprise. 156

Continuous Diagnostics and Mitigation 157

The SCuBA TRA will draw insight and guidance from the CISA CDM Program to provide a dynamic approach to 158

fortifying government network and system cybersecurity. [8] The CDM Program will continue to deliver 159

cybersecurity tools, integration services, and dashboards that help participating agencies improve their security 160

posture. Additionally, the CDM Program is continuing to develop guidance for agencies focused on the 161

integration of cloud platforms into CDM dashboards. 162

CISA Zero Trust Maturity Model 163

CISA’s Zero Trust Maturity Model is one of many roadmaps that agencies may reference as they transition 164

toward a ZT architecture. [9] The maturity model’s goal is to assist agencies in developing their ZT strategies and 165

implementation plans. The model also presents ways in which various CISA cybersecurity programs can support 166

ZT solutions across agencies. 167

extensible Visibility Reference Framework Guidebook 168

The purpose of eVRF is to define the concepts, requirements, and mechanisms for CISA, FCEB agencies, and 169

other partners to identify, collect, and evaluate cyber visibility to mitigate threats. [10] The eVRF Guidebook is an 170

instruction manual for eVRF; it defines and describes key concepts, roles and responsibilities, and workflows. It 171

identifies the demand for visibility as a unique characteristic of cybersecurity, with a structure and workflow that 172

defines visibility for different portions of a digital environment. An eVRF workbook defines specific visibility 173

surfaces and can be implemented with an Excel spreadsheet or a software application. The implementation of 174

eVRF workbooks will continue to evolve over time. 175

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 6 TLP:WHITE

4.2 Federal Cloud Security Guidance 176

Federal Risk and Authorization Management Program 177

FedRAMP provides a standardized approach to security authorizations for cloud service offerings. [11] This 178

program provides cloud service offerings to the federal government, adopts innovative cloud services to meet 179

agency mission needs, and acts as a third party to perform initial and periodic security assessments. The cloud 180

business application will follow the FedRAMP authorization process to properly authorize the cloud service 181

offering. 182

OMB Memorandum: Moving the U.S. Government Toward Zero Trust 183

Cybersecurity Principles 184

The OMB Zero Trust Architecture (ZTA) strategy memorandum (M-22-09) sets forth specific cybersecurity 185

standards and objectives for agencies to fulfill as part of their adoption of ZT architectures. [12] The SCuBA TRA 186

aligns with these objectives and standards. Agencies should consider the actions specified in the memo and 187

their own ZT strategies when designing and implementing security for their cloud business applications to 188

ensure they meet ZT goals. 189

OMB Memorandum: Improving the Federal Government’s Investigative 190

and Remediation Capabilities Related to Cybersecurity Incidents 191

The OMB memorandum (M-21-31) establishes logging, log retention, and log management requirements for 192

agencies. [4] Although its requirements are broader than cloud environments, they do apply to cloud; thus, 193

agencies will need to ensure they continue to fulfill these requirements in deploying and maintaining their cloud 194

business applications. 195

Federal ICAM Architecture Introduction 196

The Federal Identity, Credential, and Access Management (FICAM) Architecture Introduction describes the 197

basics of ICAM, the FICAM architecture, and how to use the information to facilitate enterprise ICAM practices at 198

an agency. [13] See Section 6.1 for additional information. 199

5. Threats to Cloud Business Applications 200

As the threat landscape constantly evolves, an authoritative source for tracking, documenting, and mitigating 201

threats is imperative. Multiple sources for characterizing threats can be used to inform an architecture to secure 202

cloud business applications. Threat identification sources for cloud applications are either open-source or closed 203

source (proprietary/classified). The MITRE ATT&CK

framework will be the primary open-source taxonomy for 204

characterizing threat sources and TTPs for SCuBA. 205

The MITRE ATT&CK matrix for SaaS and relevant vendor-specific matrices will be used to outline security 206

threats. The MITRE ATT&CK framework is a knowledge base and authoritative source for cyber adversary 207

behavior. The framework outlines various phases of a cyberattack lifecycle and the targets malicious cyber 208

actors are known to exploit. ATT&CK includes only adversarial tactics and techniques based on real-world 209

observations as of the date of the posted matrix, reducing its ability to characterize novel or emerging 210

adversarial activities. eVRF accounts for these emerging threats by characterizing the visibility available for 211

cloud business applications, regardless of whether specific attacker actions have been cataloged in ATT&CK. 212

eVRF further permits mapping of those observables to the ATT&CK techniques applicable to the business 213

applications domain. In this way, eVRF visibility surface definitions and coverage maps can identify visibility that 214

should be available and characterize the visibility that is available within a given system, respectively. See 215

Section 0 for additional details. 216

6. Securing Cloud Business Applications 217

This section describes the essential components of security services and capabilities to secure and harden 218

cloud business applications. These security services and capabilities prevent and mitigate vulnerabilities and 219

threats from affecting the cloud business applications during implementation, configuration, and administration. 220

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 7 TLP:WHITE

In addition, once in place, these security services and capabilities harden the system to improve the security of 221

the cloud business applications and the platform where the applications are hosted. 222

The set of configurations and security services is based on the previously identified business capabilities, 223

threats to those capabilities, and related CISA efforts. Agency-specific implementations of these services should 224

adhere to their specific risk profiles and tolerances. Also, these security configurations, when monitored in real 225

time, serve as a proactive security approach to identify potential cybersecurity threats and help safeguard the 226

environment. 227

Figure 6-1 illustrates the security and visibility points for SCuBA. Each of the points maps to one or more 228

sections of the SCuBA TRA, as shown in Table 6-1. Additionally, from a ZT perspective, while the security of these 229

applications intersects with each of the pillars described in the ZT Maturity Model, the application security 230

boundary most closely aligns with the application workload pillar. 231

232

Figure 6-1. SCuBA Security and Visibility View 233

Table 6-1 maps the numbered security and visibility points to the sections below that cover them . 234

Table 6-1. Security and Visibility Mapping to Sections 235

Security Enforcement

Point/Visibility

Relevant Sections

Section 6.2 Secure Cloud Access from Any Location

Section 6.5.1 Desktop Endpoint Security

Section 6.5.2 Mobile Endpoint Security

Section 6.6 Application Security Configuration

Section 6.3 External Email Protections

Section 6.6.1 Data Sharing and Exfiltration Protection

Section 6.1 Identity, Credential, and Access Management

Section 6.4 Protective Domain Name System

Section 6.7 Cyber Visibility and the eVRF Analytical Framework

Section 6.8 Telemetry Generation and Processing

All

Section 6.7 Cyber Visibility and the eVRF Analytical Framework

Section 6.8 Telemetry Generation and Processing

Section 6.9 Shared Responsibility Model

6.1 Identity, Credential, and Access Management 236

ICAM is a core tenet of ZT, and it facilitates cybersecurity risk management decisions. ICAM is the set of tools, 237

policies, and systems that an agency uses to enable the right individual to access the right resource, at the right 238

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 8 TLP:WHITE

time, and for the right reason, in support of federal business objectives. Government Services Administration 239

(GSA) provides guidance on establishing an ICAM program through the implementation of FICAM architecture 240

and the National Institute of Standards and Technology (NIST) Special Publication 800-63-3, Digital Identity 241

Guidelines. The FICAM architecture provides the overarching architecture for establishing requirements and 242

guidelines for an ICAM program. NIST’s Special Publication 800-63-3 provides the mandatory guidelines to be 243

used to determine various levels of identity proofing, registration, authenticators, authentication protocols, and 244

federation for agencies implementing digital identity services. [14] 245

Typically, agencies have a pre-existing ICAM program such as the one shown in Figure 6-2. This infrastructure 246

provides central management of identities, issues logical credentials (typically personal identity verification [PIV] 247

cards or derived PIV credentials), and, in some advanced cases, provides central management of roles or 248

entitlements. 249

250

Figure 6-2. ICAM Practice Areas and Supporting Elements [13] 251

A common deployment of business applications is to federate the pre-existing ICAM infrastructure (e.g., through 252

Microsoft Active Directory Federated Services) with the business applications. (Various configurations are 253

possible, but the details are out of scope of this document.) However, because such a deployment reuses pre-254

existing infrastructure, certain cybersecurity compromises of on-premises infrastructure could also pose risks to 255

the cloud. The FICAM architecture provides guidance to the Federal Government to design, plan, and execute 256

common ICAM processes. [13] FICAM recommends that only end-user accounts should be federated, and OMB 257

ZTA strategy (M-22-09) states administrative accounts should be authenticated using phishing-resistant 258

multifactor authentication. 259

An alternative architecture that is becoming more prevalent for agencies leverages a cloud-based Identity as a 260

Service (IDaaS) provider for authentication directly in the cloud (e.g., using a PIV-based credential). Such an 261

architecture adopts a shared responsibility model in which the IDaaS provider assumes responsibility for 262

security of key components of the platform (e.g., cryptographic material required for federation protocols) while 263

the agency remains responsible for secure configuration. Some responsibilities, such as monitoring for threats, 264

are shared between the agency, the vendor, and CISA in this model. 265

CISA recommends that agencies explore, in detail, the tradeoffs between these two models as relevant to their 266

existing environment and mission goals. 267

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 9 TLP:WHITE

ICAM is critical to securing a cloud application. Many parts of ICAM should be managed enterprise-wide (identity 268

lifecycle, issuance of root credentials, and privilege role assignment, etc.). However, some parts of access 269

management are configured specifically within the cloud business applications. This is especially true with 270

respect to managing end-user access. One important aspect is strong administrative controls and least privilege. 271

Policies—such as Conditional Access in M365 or Context Aware Access in GWS—enable limiting access only to 272

authorized and up-to-date devices. Such policies should be enabled to tie together the Secure Cloud Access 273

(SCA) and endpoint protection technologies. These policies “close the loop” by ensuring that agency data is only 274

accessible by devices that follow the agency’s desired security posture. CISA is developing secure configuration 275

baselines specific to cloud-native identity and access management services for M365 [10] and GWS to support 276

these identity- and access-focused considerations. 277

6.2 Secure Cloud Access from Any Location 278

With the growth of mobile, telework, and cloud applications, traditional approaches to secure cloud access no 279

longer meet the needs of the FCEB. The TIC program recognizes this and articulates a new model for securing 280

access to cloud applications. The SCuBA TRA uses the TIC 3.0 guidance as the foundation for securing user 281

access to business applications; this capability is called, "secure cloud access" or "SCA." SCA solutions should be 282

part of agencies’ cloud business application deployment. In the broader cloud market, vendors use terms such 283

as Zero Trust Network Access, Cloud Access Security Broker (CASB), Secure Email Gateway (SEG), Secure 284

Access Service Edge, and others to refer to products and services that target different aspects of SCA. The 285

broader market is rapidly evolving as these discrete solutions converge. 286

SCA solutions give users the ability to securely access the agency’s business applications that reside on a CSP. 287

These business application users may be on the enterprise network, in a branch office, on a remote device, or 288

on a mobile device. A non-person entity

(NPE) may also be a user of agency business applications. The SCA 289

solution, along with the security services embedded in the destination CSP and the source workstation or device 290

(e.g., endpoint detection and response [EDR]) follow the TIC guidance. Different use cases and security patterns 291

may require other technical solutions. SCA security functions may be the same as, or complement, the source 292

workstation or device and CSP security functions. For example, SCA functions may be provided by the CSP, the 293

source workstation or device, a third-party vendor, or all of these. See Figure 6-3 for an overview graphic of a 294

SCA concept. 295

The SCuBA TRA provides only an introduction to the SCA topic. TIC 3.0 guidance documents can provide 296

additional information on design alternatives for different SCA use cases. 297

NPE: An entity with a digital identity that acts in cyberspace but is not a human actor. This can include

organizations, hardware devices, software applications, and information artifacts. Source(s): CNSSI 4009-

2015 from DHS OIG 11-121.

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 10 TLP:WHITE

298

Figure 6-3. SCA Concept 299

6.3 External Email Protections 300

Email is often used as an entry point to agency environments, as shown in Figure 6-4. It is used by adversaries 301

for delivering both phishing links and malware, as seen in recent high-visibility attacks. Email-related risks are 302

typically addressed with a combination of native security capabilities built into the CSP’s products as well as 303

independent third-party offerings. Historically, these capabilities for federal executive branch agencies were 304

provided by EINSTEIN 3 Accelerated (E3A), administered by CISA. Typically, email security solutions (whether 305

provided as a native security capability in a CSP offering or as a separate product) include the following: 306

• Filtering and Tagging: Email filtering of all messages (e.g., ingress, egress, internal) for detecting malware, 307

identifying spam, and tagging for agencies. This includes the use of both government (i.e., CISA, agency) 308

and commercial indicators and attributes (behavioral and reputational) for malware detection, and spam 309

identification and tagging for agencies, including the use of both government (i.e., CISA, agency) and 310

commercial indicators and attributes (behavioral and reputational). 311

• Log Visibility: Visibility into email attributes should be provided to both CISA and agency security operations 312

personnel. 313

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 11 TLP:WHITE

• Authentication and Integrity: Modern techniques for ensuring sending and receiving email servers are 314

mutually authenticated and messages are not manipulated in transit. This is accomplished using Domain-315

based Message Authentication, Reporting, and Conformance, Sender Policy Framework, and Domain Keys 316

Identified Mail. 317

• Additional Features: Other key features in robust email security protections include automated indicator 318

provisioning, threat intelligence, advanced analytics, reporting, cyber hunt support and incident 319

response, sandboxing, detonation, and the ability to incorporate third-party security services. 320

321

Figure 6-4. External Email Flow 322

CISA is also developing secure configuration baselines (see Section 6.6) that relate to email security. Identity-323

related configuration requirements and baselines in development also support email security. Agencies should 324

integrate external email protections and implement secure configuration baselines for critical cloud services 325

that affect email security, such as Exchange Online, Azure Active Directory, and Google Cloud Identity. 326

6.4 Protective Domain Name System 327

In addition to SCA solutions that apply policy to and collect telemetry from network flows between endpoints and 328

cloud applications, domain name system (DNS) lookup provides a widely used insertion point in internet 329

infrastructure to implement cybersecurity policy and visibility. Secure DNS solutions’ key capabilities include: 330

• internet protocol (IP) v4 and v6 source address verification; 331

• query filtration by IP, domain, subdomain, or record type; 332

• auto-blockage of newly created domains, “look-alike” homoglyphs, nonstandard query structures, and 333

known risky domains; 334

• self-monitoring heuristics to gauge percentage of correctly permitted (benign) queries, correctly blocked 335

(malign) queries, and anomalous false positives; 336

• direct bypass, for use cases where crucial DNS queries must go through; 337

• location blocking; 338

• DNS over Transport Layer Security (DoT) and DNS over Hypertext Transport Protocol Secure; and 339

• telemetry collection for both the agency and CISA (i.e., to discover outbound Command and Control traffic). 340

CISA is developing a new DNS service to replace the legacy E3A domain sinkholing functionality. Agencies 341

should deploy the CISA DNS security solution (when available) or equivalent protective DNS capabilities, 342

including customizable DNS query filtration, such as “allow,” “deny” (block), “overwrite” (rewrite) response, or 343

“sinkhole” (suppression), based on domain parameters, encrypted DNS support, DoT support, DNS security 344

extensions support, and compatibility with current Internet Engineering Task Force (IETF) DNS protocol 345

extensions. 346

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 12 TLP:WHITE

6.5 Endpoint Security Services 347

Managing endpoints (both mobile and desktop) is critical to securing cloud business applications and to support 348

a ZT approach. Although mobile security is not within the scope of the SCuBA project itself, it is expected that 349

agencies will need to deploy and configure their cloud business applications to enable access from their mobile 350

and desktop devices. 351

6.5.1 Desktop Endpoint Security 352

SCuBA relies upon endpoint security technologies for both policy and visibility. The cloud business application 353

access policies should be configured to limit access to agency data based on host posture assessment (see 354

Section 6.6). In other words, the policies should enforce that all sensitive data requests come from agency-355

managed devices that comply with agency endpoint security policies, such as operating system version and 356

patch level (or devices explicitly authorized by risk-based policy decisions supporting mission needs). EDR 357

products can be used to collect the signals necessary for these policy decisions to be made and to provide 358

critical visibility into the endpoints that enable cybersecurity response. 359

Agencies should leverage the CDM Program to obtain and deploy EDR technologies in their environment. 360

Additionally, the cloud business application should be configured to leverage signals from the EDR products to 361

govern access to private agency data. 362

Endpoints not managed by the agency, such as those of guests, collaborators, partners, customers, or even 363

agency users’ personal devices, will have limited opportunities for agency policy enforcement or evaluation. The 364

breadth of access to agency data should reflect this limited insight by reducing or even prohibiting access to 365

sensitive information. 366

6.5.2 Mobile Endpoint Security 367

Similar access policies should also be configured for agency-managed mobile endpoints. To protect and manage 368

mobile devices and applications, the CDM Program helps agencies deploy Enterprise Mobility Management 369

(EMM) capabilities. [15] EMM solutions enable agencies to manage device configuration and device 370

compliance; monitor and track devices; manage allowed mobile apps; detect and address malicious mobile 371

apps via mobile threat defense and mobile application vetting; discover and respond to network-based attacks 372

and vulnerable configurations; and support the issuance and life cycle management of credentials provisioned 373

on mobile devices. Agencies’ cloud business applications should be configured to leverage signals from EMM 374

solutions in access decisions. 375

CISA also published Capacity Enhancement Guides to help enterprises and consumers improve cybersecurity of 376

their mobile devices. [16] To support agencies as they develop their ZT plans and roadmaps, CISA developed a 377

whitepaper titled “Applying Zero Trust Principles to Enterprise Mobility.” [17] The paper describes mobile 378

security technologies, explains how they support ZT principles, and identifies areas requiring additional work. 379

6.6 Application Security Configuration 380

As the federal government continues to move critical services to the cloud, it is imperative to ensure consistent, 381

effective, modern, and manageable security configurations to protect all information assets in and connections 382

to cloud services. The objective of this initiative is to move federal cybersecurity forward by helping agencies 383

keep pace with sophisticated and determined cyber threats. At the time of this writing, the SCuBA project is 384

developing and testing minimum viable security baselines that can be easily and quickly adopted across the 385

federal civilian landscape. A “Security Baseline” defines a set of basic security objectives that must be met by 386

any given service or system. (See Figure 2-1 for a visual representation of where these artifacts sit within the 387

iterative approach to the SCuBA TRA development.) 388

A key benefit of this work is that agencies using M365 and GWS can adopt these recommended cybersecurity 389

configurations. Maintaining and updating this guidance is essential to ensuring an acceptable and consistent 390

security posture. These efforts are led by CISA with input and support from interested federal agencies. The 391

baselines are also developed with an eye towards automation rather than manual repetitive tasks where 392

possible, improving consistency in application and reducing time to deployment. 393

The baselines cover the full scope of the security architecture for SCuBA, including ICAM, collaboration, cloud 394

access security broker capabilities, threat intelligence, detection, mitigation, cloud storage, cloud-native email 395

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 13 TLP:WHITE

service security, and cloud-native business applications. Additional baselines may be selected as CISA continues 396

maturing SCuBA. 397

6.6.1 Data Sharing and Exfiltration Protection 398

Another SCuBA security concern is data sharing and data exfiltration risk. Agencies must balance the need to 399

collaborate with other stakeholders outside the agency (and thus share content, calendars, etc.) with the need 400

to protect agency data.. At a minimum, agencies should use cloud business applications’ built in rules systems 401

to detect cross-tenant data sharing. These rules can be used to discover exfiltration of important agency data. In 402

some cases, agencies may also choose to block cross-tenant sharing of certain types of data (e.g., share 403

busy/free status but not documents), depending on mission requirements. 404

6.7 Cyber Visibility and the eVRF Analytical Framework 405

Agencies will need to collect and apply cyber visibility, both operational and technical (e.g., insights into assets, 406

users, systems, data, events, logs), to detect potentially malicious activities associated with the use of cloud 407

business applications. These activities include the application of key eVRF concepts. The fundamental purpose 408

of the eVRF Guidebook is to define the concepts, requirements, and mechanisms for CISA, FCEB agencies, and 409

other partners to collect and apply cyber visibility to mitigate threats. In the context of SCuBA, an applicable 410

eVRF concept is that of the visibility surface, which is defined as “a digital environment for which cyber-411

observable data exists or should exist.” [10] The application logs, endpoint access logs, proxy logs, service logs, 412

reports, and alerts generated with the monitoring, auditing, and alerting services are essential parts of this 413

digital environment and will provide evidence of malicious and benign activity. Section 6.1 identifies sources for 414

such telemetry. Analysts from agencies, CISA, and vendors each have a unique role and associated visibility 415

demands for telemetry from these sources that are stored in the Telemetry Hosting solution. These visibility 416

demands will need to be accommodated when deploying and configuring services to ensure coverage. Use of 417

the eVRF workflow can assist in characterizing visibility completeness. 418

The eVRF Guidebook identifies three phases of the workflow for accomplishing cyber visibility: (1) define visibility 419

surface, (2) produce visibility coverage maps, and (3) generate coverage comparisons for analysis and insights. 420

Figure 6-5 describes these process phases and includes a detailed description for each. The execution steps are 421

provided in the referenced document. [10] 422

423

424

Figure 6-5. eVRF Workflow 425

The eVRF Guidebook identifies roles and responsibilities for CISA, organizations (agencies), and vendors/service 426

providers. [10] In summary, CISA has the responsibility for developing an eVRF visibility surface definition and 427

requirements coverage map in an eVRF workbook. Agencies are to use this eVRF workbook to guide their 428

internal policies and align with CISA’s cyber visibility requirements, and vendors/service providers can work to 429

reduce or eliminate visibility gaps in their offerings. 430

An eVRF workbook can be implemented as a purpose-built software application, using a spreadsheet or tables. 431

Ultimately, a purpose-built software application would offer the most flexible way to create and edit a visibility 432

surface definition and coverage maps. 433

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 14 TLP:WHITE

6.8 Telemetry Generation and Processing 434

The quality and completeness of the visibility offered to cyber analysis is dependent upon the observation points 435

and telemetry-generating system components. The following subsections outline what services agencies will 436

need to use to ensure effective security visibility and management of cloud business applications. In 437

implementing these services, agencies should comply with the logging requirements issued by OMB M-21-31 [4] 438

and consult NIST Special Publication 800-92 [18] for additional guidance on security log management.

This will 439

enable agencies to collect the logs they need for their own security operations and to provide additional visibility 440

to CISA. 441

6.8.1 Logging 442

Agencies will need to configure their cloud services to generate logs for their applications to enable various 443

cybersecurity outcomes: improved visibility, asset management, incident response, and more. They are also 444

essential to fulfill many compliance requirements. By leveraging the eVRF workbook for SCuBA, agencies can 445

determine the necessary log data that must be collected to enable these outcomes and detect different TTPs as 446

well as what logs must be shared with CISA. 447

To ensure appropriate levels of visibility, logs from multiple observation points must be collected. Figure 6-6 448

presents an alternate SCuBA security and visibility view that emphasizes the collection of telemetry and logs. 449

450

Figure 6-6. SCuBA Telemetry 451

452

NIST is in the process of revising the NIST Special Publication 800-92 (https://csrc.nist.gov/Projects/log-

management).

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 15 TLP:WHITE

In cloud business applications, logs should be collected from each of the key building blocks previously 453

identified: 454

• The SCA solution 455

• The endpoint solutions 456

• The SCuBA application platform (M365/GWS) 457

• The security services, such as the ICAM solution (whether on-premises or cloud-based) and the secure 458

DNS solution 459

As shown in Figure 6-6, the telemetry and logs can be aggregated via the Telemetry Hosting solution to facilitate 460

analysts’ needs and internal agency monitoring, auditing, alerting, and threat detection activities. An eVRF 461

visibility surface definition and OMB M-21-31 [4] logs should capture both key business events (e.g., 462

send/receive email, document sharing outside of tenant) as well as configuration changes (e.g., new user 463

creation, policy updates) as both can be indicative of cybersecurity events. Logs should be generated in an 464

automated fashion. They can be configured to capture numerous pieces of contextual information about cloud 465

activities, accesses, and resource states; this often includes fields or attributes such as associated user ID, 466

resource ID, Application Programming Interface (API) name, timestamp, IP addresses, etc. Specific metadata are 467

identified in more detail in the eVRF visibility surface definition. Agencies will need to manage issues associated 468

with scaling, retention, access, privacy, provenance, exportability, and timeliness—among other issues—of their 469

logs as well as ensure that the logs that must be shared with CISA in real time are properly delivered as per the 470

NCPS Cloud Interface Reference Architecture. [5], [6] 471

6.8.2 Monitoring 472

While some logs may be stored for record keeping and compliance purposes, others will be monitored, audited, 473

and analyzed as part of broader agency security posture management. Agencies should therefore incorporate 474

logs from their cloud business applications into their monitoring services to update tracking metrics, conduct 475

resource mapping, and generate security reports, which will in turn facilitate auditing, alerting, and threat 476

detection. The same applies for new security services deployed as part of SCuBA adoption. 477

6.8.3 Auditing 478

Agencies should conduct further analysis of their application logs and security reports through security auditing. 479

This can address various contextual questions for a potential event, such as which users, processes, services, or 480

applications were involved; what was done; where it took place; when it occurred and over what time period; 481

how it occurred; and the impacts. Auditing services allow agencies to better understand what is happening 482

within (and to) their cloud environments and ensure they are operating as desired. This is a more labor-intensive 483

process than automated monitoring and report generation, as it typically involves a human policy decision point 484

(as opposed to a technology policy decision point). Periodic audits can further seek to discern not only whether 485

given transactions can occur, but whether they should occur in normal operating conditions and states. The 486

additional review of organizational visibility (i.e., the awareness of business functions, priorities, risks, and 487

collaboration agreements) enhances auditor precision and can provide further insights to an agency. 488

6.8.4 Alerting 489

Agencies should create alerts for their business applications that automatically generate based on their 490

monitoring and auditing data. Alerts will enable agencies to quickly identify various issues with business 491

applications, such as misconfigurations, unauthorized access, and privilege changes, as well as other 492

anomalous activities for review and remediation. Such alerts will represent the result of defects or heuristically 493

derived detections and should be given preferential treatment in analysis tools and dashboards (with respect to 494

the raw data used to generate the alerts). Agencies should integrate these alerts into their existing Security 495

Operations Center (SOC) procedures and leverage their existing Security Information and Event Management 496

(SIEM) and Security Automation, Orchestration, and Response (SOAR) tooling to respond to security alerts. 497

6.8.5 Threat Detection 498

Agencies can leverage a variety of tools and services to detect and mitigate potentially malicious activity taking 499

place within or against their cloud environments through business applications. These can include threats such 500

as denial of service, data exfiltration, malware injection, unauthorized privilege escalation and account creation, 501

etc. Threats may be detected using automated means or manual discovery. Data visualization tools and 502

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 16 TLP:WHITE

dashboards can assist agency analysts in detecting threats against agency cloud business applications. 503

Agencies should review threat-detection services offered natively by their service provider as well as stand-alone 504

and third-party offerings to incorporate anomaly detection, machine learning, threat intelligence, etc., within 505

their threat detection capabilities for their cloud business applications. Agencies should test these services to 506

benchmark fidelity in the alerts generated and latencies in detection. Agencies should also update their logging, 507

monitoring, auditing, and alerting policies and procedures based on lessons learned from their threat detection 508

capabilities (i.e., to incorporate analytics for newly discovered threats, reduce false positives, and expand 509

visibility coverage to mitigate gaps). 510

6.9 Shared Responsibility Model 511

The SCuBA TRA relies on a shared responsibility model, as shown in Figure 6-7 and described in the following 512

subsections, between the agency, CISA, and the selected vendors. Each plays a critical role in ensuring a robust 513

security posture and achieving the desired security outcomes. This is true both with respect to protective 514

security controls as well as visibility, detection, and response. 515

516

Figure 6-7. Shared Responsibility Model 517

6.9.1 Protective Security Controls and Services 518

• Agencies: Agencies are responsible for properly configuring their chosen cloud business application 519

platform in accordance with the SCuBA solution architecture documents. Agencies are also responsible for 520

ensuring that their SCuBA deployment leverages appropriate capabilities of their other security services as 521

discussed in Sections 6.1 and 6.5. 522

• Vendors: Vendors are responsible for securing the underlying SaaS platform behind the business 523

applications. Vendors should also offer agencies the necessary product capabilities to implement the 524

required security controls, including integrations with independent software vendor solutions (e.g., to 525

provide email security services or identity services) if necessary. 526

• CISA: CISA is responsible for defining the baseline security requirements, architectures, and configurations 527

necessary to realize the SCuBA vision. CISA is also responsible for developing shared services to 528

implement pieces of the TRA. 529

6.9.2 Visibility, Detection, and Response 530

• Agencies: Agencies are responsible for first-line security operations, such as alert triage and response to 531

limited-scope incidents. Agencies collect and retain logs per OMB M-21-31 and CISA guidelines (both the 532

CISA logging guidance as well as the eVRF CISA visibility requirements). Agencies can leverage CISA-533

provided shared services to enhance their logging and security monitoring operations. Agencies are also 534

encouraged to coordinate with their vendors and/or service providers on the application of telemetry 535

configuration and visibility coverage map generation, which may include feature requests in future product 536

releases. 537

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 17 TLP:WHITE

• Vendors: Cloud business application providers can share vulnerability and breach-related information with

538

CISA and agencies to enhance situational awareness and facilitate response activities. Additionally,

539

vendors can identify trends and threat activities across sectors and service offerings. They can respond to

540

threats that are undetectable to their tenants and update their offerings to mitigate vulnerabilities and

541

adversarial campaigns. Vendors can also share information about updates and changes to their products,

542

share guidance on how to effectively use their offerings as engineered, and provide formal instruction and

543

training opportunities to ensure consistent understanding of product limitations and features.

544

• CISA: CISA’s duties include refining visibility requests, updating baselines, and providing response support.

545

One of CISA’s primary responsibilities is to assist agencies in threat discovery and remediation. Thus, CISA

546

will engage with FCEB agencies to facilitate data acquisition of cloud logs and telemetry to ensure delivery

547

aligns with CISA’s preferences for timeliness, frequency, format, and other attributes, as described in the

548

National Cybersecurity Protection System Cloud Interface Reference Architecture Volume Two: Reporting

549

Pattern Catalog. [6] This telemetry will enable CISA’s analysis, incident response, and threat hunting

550

activities. CISA will engage cloud vendors to mitigate security and visibility gaps providing enhanced

551

security for cloud business applications. CISA will also coordinate with cloud vendors to mitigate risks

552

facing FCEB agencies’ cloud services through information sharing and the deployment of security services.

553

554

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 18 TLP:WHITE

7. References

[1]

117th Congress, "H.R. 1319 - American Rescue Plan Act of 2021," Senate and House of

Representatives of the United States of America, Washington, D.C., 2021.

[2]

116th Congress, "H.R. 6395, National Defense Authorization Act for Fiscal Year 2021,"

Senate and House of Representatives of the United States of America, Washington,

D.C., 2021.

[3]

CISA, United States Digital Service, and Federal Risk and Authorization Management

Program, "Cloud Security Technical Reference Architecture," 2021. [Online].

Available: https://www.cisa.gov/cloud-security-technical-reference-architecture.

[4]

Office of Management and Budget, "Improving the Federal Government’s

Investigative and Remediation Capabilities Related to Cybersecurity Incidents," 27

August 2021. [Online]. Available: https://www.whitehouse.gov/wp-

content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-

Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf.

[Accessed 15 November 2021].

[5]

CISA, "CISA NCPS Cloud Interface Reference Architecture Volume 1: General

Guidance," Cybersecurity and Infrastructure Security Agency, Arlington, VA, 2020.

[6]

CISA, "National Cybersecurity Protection System Cloud Interface Reference

Architecture Volume Two: Reporting Pattern Catalog," Cybersecurity and

Infrastructure Security Agency, Arlington, VA, 2020.

[7]

CISA, "Trusted Internet Connections Guidance Repository," Cybersecurity &

Infrastructure Security Agency (CISA), [Online]. Available: https://www.cisa.gov/tic-

guidance. [Accessed February 2022].

[8]

CISA, "Continuous Diagnostics and Mitigation CDM)," CISA CDM Program

Management Office, [Online]. Available: https://www.cisa.gov/cdm. [Accessed

January 2022].

[9]

CISA , "Zero Trust Maturity Model," June 2021. [Online]. Available:

https://www.cisa.gov/zero-trust-maturity-model. [Accessed Jan 2022].

[10]

CISA, "CISA Blog on SCuBA," [Online]. Available:

https://www.cisa.gov/blog/2022/03/31/secure-cloud-business-applications.

[11]

General Services Administration, "FedRAMP," [Online]. Available:

https://www.gsa.gov/technology/government-it-initiatives/fedramp. [Accessed

January 2022].

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 19 TLP:WHITE

[12]

Office of Management and Budget, "Moving the U.S. Government Towards Zero Trust

Cybersecurity Principles," 26 January 2022. [Online]. Available:

https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf.

[Accessed Febuary 2022].

[13]

General Services Administration (GSA), "Federal ICAM Architecture Introduction,"

IDManagement.gov, 6 January 2021. [Online]. Available:

https://playbooks.idmanagement.gov/arch/. [Accessed January 2022].

[14]

P. Grassi, M. Garcia and J. Fenton, "NIST Special Publication 800-63-3, Digital Identity

Guidelines," June 2017. [Online]. Available: https://pages.nist.gov/800-63-3/sp800-

63-3.html. [Accessed November 2021].

[15]

CISA, "Continuous Diagnostics and Mitigation Program, Technical Capabilities, Vol 2:

Requirements Catalog," Cybersecurity and Infrastructure Security Agency (CISA),

Arlington, VA, 2020.

[16]

CISA, "CISA Releases Capacity Enhancement Guides to Enhance Mobile Device

Cybersecurity for Consumers and Organizations," Cybersecurity & Infrastructure

Security Agency, 24 November 2021. [Online]. Available:

https://www.cisa.gov/uscert/ncas/current-activity/2021/11/24/cisa-releases-

capacity-enhancement-guides-enhance-mobile-device. [Accessed December 2021].

[17]

CISA, "Applying Zero Trust Principles to Enterprise Mobility. (DRAFT)," Cybersecurty

& Infrastructure Security Agency, Arlington, VA, Not released to date..

[18]

National Institute of Standards and Technology (NIST), "NIST Guide to Computer

Security Log Management," 13 September 2006. [Online]. Available:

https://csrc.nist.gov/publications/detail/sp/800-92/final. [Accessed 15 November

2021].

[19]

Federal Mobility Group, "International Travel Guidance for Government Mobile

Devices DRAFT," Federal Mobility Group, Arlington, VA, 2021.

[20]

Federal Mobility Metrics Working Group (FMMWG) , "Federal Mobility Metrics

Working Group (FMMWG)," Federal Mobility Group (FMG) and Advanced Technology

Academic Research Center (ATARC), Arlington, VA, 2021.

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 20 TLP:WHITE

Appendix A. Glossary

Application Programming Interface (API): A system access point or library function that has a well-defined syntax

and is accessible from application programs or user code to provide well-defined functionality.

Cloud Service Provider (CSP): An external company that provides a platform, infrastructure, applications, and/or

storage services for its clients.

Continuous Diagnostics and Mitigation (CDM): A CISA program that provides a dynamic approach to fortifying

government networks and systems cybersecurity by delivering cybersecurity tools, integration services, and

dashboards that help participating agencies improve their security posture.

Domain Name System (DNS): A system that stores information associated with domain names in a distributed

database on networks. DNS translates IP addresses into human-understandable names.

Enterprise Mobility Management (EMM): A suite of services and technologies that enables an agency to secure

the use of mobile devices (e.g., tablets, smartphones, and e-readers) per the agency’s policies. Components of

an EMM include mobile device management, mobile application management, and mobile identity

management.

extensible Visibility Reference Framework (eVRF): Defines the concepts, requirements, and mechanisms for

CISA, FCEB agencies, and other partners to collect and apply cyber visibility to mitigate threats. eVRF was

created in response to Executive Order 14028, “Improving the Nation’s Cybersecurity.”

Federal Civilian Executive Branch (FCEB): A subset of U.S. federal departments and agencies that excludes the

Department of Defense and agencies in the intelligence community.

Identity, Credential, and Access Management (ICAM): A fundamental and critical cybersecurity capability that

ensures the right people and NPEs have the right access to the right resources at the right time.

Internet Engineering Task Force (IETF): A large, open, international internet standards body comprised of

network designers, operators, vendors, and researchers interested in how the internet architecture evolves and

the smooth operation of the internet. The IETF technical work of developing open standards through open

processes is done in working groups that are organized by topic into several areas.

Mobile Application Vetting (MAV): Performs enterprise-level security analysis of managed apps and their libraries

prior to deployment and throughout the lifecycle of the apps. Integration of EMM with MAV provides the ability

for the EMM to apply mitigations (e.g., uninstall app or block access to enterprise resources).

Mobile Threat Defense (MTD): Helps detect the presence of malicious apps or software, malicious activity, and

connections to deny-listed websites or networks. Integration of EMM with MTD provides the ability for MTD to

notify the EMM of malicious apps or activity on a mobile device so that the EMM can provide mitigations.

Multifactor Authentication (MFA): An authentication system that requires more than one distinct authentication

factor for successful authentication. Multifactor authentication can be performed using a multifactor

authenticator or a combination of authenticators that provide different factors.

Secure Cloud Access (SCA): A subset of remote access solutions that provide the ability for a trusted user on a

remote workstation to securely access the agency’s business application on a cloud service provider.

Security Information and Event Management (SIEM): An application that is used to gather security data from

across systems to facilitate monitoring, analysis, triaging, and alerting through a single interface.

Security Operations Center (SOC): A centralized operations center for monitoring, analyzing, detecting, and

responding to security information and security incidents.

Security Orchestration, Automation, and Response (SOAR): A platform or collection of technologies for

coordinating, defining, automating, and executing tasks to analyze and respond to security data and security

incidents. This often includes threat and vulnerability management technologies, security incident response

capabilities, and additional tools that enable automation across security operations.

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 21 TLP:WHITE

Software-as-a-Service (SaaS): The capability provided to the consumer to use the provider’s applications running

on cloud infrastructure. The applications are accessible from various client devices through either a thin client

interface, such as a web browser (e.g., web-based email) or a program interface. The consumer does not

manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or

even individual application capabilities, with the possible exception of limited user-specific application

configuration settings.

Technical Reference Architecture (TRA): A document that illustrates recommended approaches to cloud

migration and data protection, as outlined in Section 3(c)(ii) of Executive Order 14028. As the federal

government continues to transition to the cloud, the TRA will be a guide for agencies to leverage when migrating

to the cloud securely. Additionally, the document explains considerations for shared services, cloud migration,

and cloud security posture management.

Telemetry: Artifacts derived from security capabilities that provide visibility into security posture.

Zero Trust (ZT): Per Executive Order 14028, “the term ‘‘Zero Trust Architecture’’ means a security model, a set of

system design principles, and a coordinated cybersecurity and system management strategy based on an

acknowledgement that threats exist both inside and outside traditional network boundaries. … In essence, a

Zero Trust Architecture allows users full access but only to the bare minimum they need to perform their jobs. If

a device is compromised, zero trust can ensure that the damage is contained. The Zero Trust Architecture

security model assumes that a breach is inevitable or has likely already occurred, so it constantly limits access

to only what is needed and looks for anomalous or malicious activity.”

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 22 TLP:WHITE

Appendix B. Abbreviations

Abbreviation

Definition

API

Application Programming Interface

ATT&CK

[MITRE] Adversarial Tactics, Techniques, and Common Knowledge

BYOD

Bring Your Own Device

CASB

Cloud Access Security Broker

CDM

Continuous Diagnostics and Mitigation

CISA

Cybersecurity and Infrastructure Security Agency

CSP

cloud service provider

DHS

Department of Homeland Security

DNS

domain name system

DoT

DNS over Transport Layer Security

E3A

EINSTEIN 3 Accelerated

EDR

endpoint detection and response

EMM

Enterprise Mobility Management

eVRF

extensible Visibility Reference Framework

FCEB

Federal Civilian Executive Branch

FedRAMP

Federal Risk and Authorization Management Program

FICAM

Federal Identity, Credential, and Access Management

GSA

Government Services Administration

GWS

Google Workspace

ICAM

Identity, Credential, and Access Management

IDaaS

Identity as a Service

IETF

Internet Engineering Task Force

internet protocol

information technology

M365

Microsoft 365

MAV

mobile application vetting

MFA

multi-factor authentication

MTD

Mobile Threat Defense

NCPS

National Cybersecurity Protection System

NIST

National Institute of Standards and Technology

NPE

non-person entity

OMB

Office of Management and Budget

pDNS

protective domain name system

PIV

personal identity verification

PSTN

Public Switched Telephone Network

Reference Architecture

SaaS

Software-as-a-Service

SCA

Secure Cloud Access

SCuBA

Secure Cloud Business Applications

TLP:WHITE

Secure Cloud Business Applications (SCuBA) Technical Reference Architecture (TRA)

Page | 23 TLP:WHITE

Abbreviation

Definition

SEG

Secure Email Gateway

SIEM

Security Information and Event Management

SME

subject matter experts

SOAR

Security Automation, Orchestration, and Response

SOC

Security Operations Center

TIC

Trusted Internet Connection

TRA

Technical Reference Architecture

TTPs

Tactics, Techniques, and Procedures

Zero Trust

ZTA

Zero Trust Architecture