CCSP Domain 1 - Cloud Concepts, Architecture, & Design.

txt 18-08-2021

1
2 CCSP Domain 1 - Cloud Concepts, Architecture, & Design
3
4 • Understand Cloud Computing Concepts
5 • Describe Cloud Reference Architecture
6 • Understand Security Concepts Relevant to Cloud Computing
7 • Understand Design Principles of Secure Cloud Computing
8 • Evaluate Cloud Service Providers
9
10 ============================================================================
==================
11
12 Understand Cloud Computing Concepts -
13
14 "Cloud computing is a model for enabling ubiquitous, convenient, on-demand
network access to a shared pool of configurable computing resources (e.g.,
networks, servers, storage, applications, and services) that can be
rapidly provisioned and released with minimal management effort or service
provider interaction.”
15
16 NIST Definition of Cloud Computing - NIST-SP 800-145
17
18 Managed Service Provider (MSP) - the consumer dictates the technology and
operating procedures.
19
20 Cloud Service Provider (CSP) - the service provider dictates both the
technology and the operational procedures.
21
22 ISO 17788 "Cloud Computing - Overview and Vocabulary"
23
24
25 Cloud Computing Roles - ISO 17788
26
27 • Cloud auditor
28 • Cloud service broker
29 • Cloud service customer
30 • Cloud service partner
31 • Cloud service provider
32 • Cloud service user
33 NIST SP 800-145 & NIST SP 800-146
34
35 • On-Demand Self Service
36 • Broad Network Access
37 • Resource Pooling
38 • Rapid Elasticity
39 • Measured Service
40
41 Describe Cloud Reference Architecture - NIST SP 800-145 & NIST SP 800-146
& ISO 17789:2014
42 • Cloud Service Customer Roles:
43 Cloud Service User
44 Cloud Service Administrator
45 Cloud Service Business Manager
46 Cloud Service Integrator
47 • Cloud Service Provider Roles:
48 Cloud Service Operations Manager
49 Cloud Service Manager
50 Cloud Service Business Manager
Page 1
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

51 Cloud Support / Care

52 Inter-cloud Provider (peering)
53 Cloud Service Security/Risk Manager
54 Network Provider
55 • Cloud Service Partner
56 Cloud Service Developer
57 Cloud Auditor
58 Cloud Service Broker
59 Cloud Service Cataegories:
60 • IaaS
61 • PaaS
62 • SaaS
63 Cloud Deployment Modles:
64 • Public Cloud
65 • Private Cloud
66 • Hybrid Cloud
67 • Community Cloud
68 Shared Considerations for Cloud:
69 • Interoperability
70 • Availability & Resililiency
71 • Portability
72 • SLA's
73 • Regulatory Issues
74 • Security
75 • Privacy
76 • Auditability
77 • Governance
78 • Maintenance
79 • Reversability
80 • Artificial Intelligence
81 • Containers
82 • Machine Learning
83 • IoT
84
85 Five Essential Characteristics of Cloud Computing - NIST defines them as:
86
87 1. On-Demand Self-Service - A consumer can unilaterally provision
computing capabilities, such as server time and network storage, as needed
automatically without requiring human interaction with each service
provider.
88
89 2. Broad Network Access - Capabilities are available over the network
and accessed through standard mechanisms that promote use by heterogeneous
thin or thick client platforms (e.g., mobile phones, tablets, laptops, and
workstations).
90
91 3. Resource Pooling - The provider’s computing resources are pooled to
serve multiple consumers using a multi-tenant model, with different
physical and virtual resources dynamically assigned and reassigned
according to consumer demand. Examples of resources include storage,
processing, memory, and network bandwidth.
92
93 4. Rapid Elasticity - Capabilities can be elastically provisioned and
released, in some cases automatically, to scale rapidly outward and inward
commensurate with demand.
94
95 5. Measured Service - Cloud systems automatically control and optimize
resource use by leveraging a metering capability at some level of
Page 2
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

abstraction appropriate to the type of service (e.g., storage, processing,

bandwidth, and active user accounts).
96
97
98 Cloud Service Models - three service models:
99
100 1. Software as a Service (SaaS) - The capability provided to the
consumer is to use the provider’s applications running on a 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 e-mail), 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.
101
102 2. Platform as a Service (PaaS) - The capability provided to the
consumer is to deploy onto the cloud infrastructure consumer-created or
acquired applications created using programming languages, libraries,
services, and tools supported by the provider. The consumer does not
manage or control the underlying cloud infrastructure, including network,
servers, operating systems, or storage, but has control over the deployed
applications and possibly configuration settings for the
application-hosting environment.
103
104 3. Infrastructure as a Service (IaaS) - The capability provided to the
consumer is to provision processing, storage, networks, and other
fundamental computing resources where the consumer is able to deploy and
run arbitrary software, which can include operating systems and
applications. The consumer does not manage or control the underlying cloud
infrastructure but has control over operating systems, storage, and
deployed applications; and possibly limited control of select networking
components (e.g., host firewalls).
105
106
107 Cloud Deployment Models - four:
108
109 1. Private Cloud - the cloud infrastructure is provisioned for exclusive
use by a single organization comprising multiple consumers (e.g., business
units). It may be owned, managed, and operated by the organization, a
third party, or some combination of them, and it may exist on or off
premises.
110
111 2. Community Cloud - provisioned for exclusive use by a specific
community of consumers from organizations that have shared concerns (e.g.,
mission, security requirements, policy, and compliance considerations). It
may be owned, managed, and operated by one or more of the organizations in
the community, a third party, or some combination of them, and it may
exist on or off premises.
112
113 3. Public Cloud - provisioned for open use by the general public. It may
be owned, managed, and operated by a business, academic, or government
organization, or some combination of them. It exists on the premises of
the cloud provider.
114
115 4. Hybrid Cloud - a composition of two or more distinct cloud
infrastructures (private, community, or public) that remain unique
entities but are bound together by standardized or proprietary technology
Page 3
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

that enables data and application portability (e.g., cloud bursting for
load balancing between clouds).
116
117
118 NOTE: As cloud computing moves from infrastructure to platform to
software, the responsibility to implement effective security controls
shifts away from the organization and toward the cloud service provider.
Called the Cloud shared responsibility model.
119
120
121 ============================================================================
==================
122
123 Understand Security Concepts Relevant to Cloud Computing
124
125 Goals of Cryptography
126
127 1. Confidentiality
128 2. Integrity
129 3. Nonrepudiation
130
131 Cryptographic Systems - Key Encryption Concepts and Definitions:
132
133 Cryptographic Keys - Symmetric algorithms & Asymmetric algorithms
134
135 Symmetric Key Algorithms - are SINGLE KEY !!! - We call that key the
PRIVATE KEY | SECRET KEY | SHARED KEY (all or any will do, but make sure
that you know we only use one key, shared by all participants in the system)
136
137 Weaknesses:
138
139 1. key distribution is a challenge / not scalable
140
141 2. NO Non-Repudiation possible because everyone has a copy of the key
142
143 3. key must be regenerated whenever anyone leaves the group of keyholders
144
145 Strength:
146
147 1. FAST !!! (in comparison to asymmetric)
148
149 Asymmetric Key Algorithms - are DUAL KEY !!! - We call the keys a PUBLIC /
PRIVATE key pair.
150
151 Each user has a distinct key pair issued to them upon entry / registration
into the system. The PUBLIC key is meant to be shared with anyone who may
need it to facilitate communication. The PRIVATE key is kept secret and
NOT SHARED.
152
153 We use OPPOSITE & RELATED keys in tandem to encrypt & decrypt TA DA!!
154
155 So, if your public key is used to encrypt a message, then ONLY your
private key can be used to decrypt that message.
156
157 That is THE ABSOLUTE HARDEST CONCEPT that you have to master about
cryptography. If you can wrap your head around that, and understand whose
key is used to do what, you can solve ANY problem or question that you
will see.
Page 4
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

158
159 Strengths:
160
161 1. adding users requires ONLY the generation of the key pair for them
162
163 2. users can be removed easily, without having to regenerate keys
164
165 3. ONLY time you typically regenerate a key is if the PRIVATE KEY of a
user has been compromised, or is suspect for some reason
166
167 4. provides confidentiality, integrity, authentication and non-repudiation
168
169 Weakness:
170
171 1. SLOW !!! (in comparison to Symmetric)
172
173 Symmetric Algorithms to know - (DES | 3-DES | IDEA | Blowfish | Skipjack |
AES)
174
175 Symmetric Key Management - the steps necessary to safeguard keys, including:
176
177 1. Creation & Distribution - three methods:
178
179 a. Offline Distribution - physical method(s) used to securely deliver
the key to someone
180
181 b. Public Key Encryption - use of Asymmetric encryption to exchange
the symmetric key securely
182
183 c. Diffie-Hellman algorithm - a key exchange algorithm used to enable
two users to exchange or negotiate a secret symmetric key that will be
used subsequently for message encryption. Does not provide for message
confidentiality but is extremely useful for applications such as Public
Key Infrastructure (PKI).
184
185 2. Storage & Destruction - Best Practices:
186
187 a. never store the key in the same system as the encrypted data
188
189 b. consider the use of split-knowledge approach for keys
190
191 3. Key Escrow & Recovery - Key escrow is a data security measure in
which a cryptographic key is entrusted to a third party.
192
193 a. Fair Cryptosystem - split knowledge approach with key shards being
held by different trusted third parties
194
195 Cryptographic Lifecycle - ALL cryptosystems have a limited lifespan based
on their ability to withstand attacks. The problem is that technological
power keeps advancing, and as a result, what is secure today may be
breakable tomorrow. Moore's law is at the heart of this issue and has to
be kept in mind when choosing a system, but also as you evaluate the
protective ability of the system over the retention period.
196
197 Asymmetric Cryptography - uses DUAL KEYS !!! - We call the keys a PUBLIC /
PRIVATE key pair.
198
199 Each user has a distinct key pair issued to them upon entry / registration
Page 5
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

into the system. The PUBLIC key is meant to be shared with anyone who may
need it to facilitate communication. The PRIVATE key is kept secret and
NOT SHARED.
200
201 We use OPPOSITE & RELATED keys in tandem to encrypt & decrypt (already
said that, but so important, I am saying it again!!)
202
203
204 RSA - most famous asymmetric cryptosystem. Named for its creators:
205
206 Ron Rivest
207 Adi Shamir
208 Leonard Adleman
209
210 Depends on the computational difficulty of factoring large prime numbers.
211
212
213 Hash Functions - take a message and mix it with a hash to derive a unique
output value, the Message Digest. Generated by the sender and sent along
with the message to the recipient for two reasons:
214
215 1. verify the Integrity of the message
216
217 2. verify the authenticity of the message (proof of origin &
non-repudiation)
218
219
220 Hash = Variable size input + hashing algorithm = fixed size output (hash
value/string)
221
222 Note: Message Digests are also called:
223
224 a. hashes
225 b. hash values
226 c. hash total
227 d. CRC
228 e. fingerprint
229 f. checksum
230 g. digital ID
231
232 What key to use?
233
234 1. encrypt a message = recipient's public key
235
236 2. decrypt a message = recipient's private key
237
238 3. digitally sign a message = sender's private key
239
240 4. verify a digitally signed message = sender's public key
241
242 Public Key Infrastructure (PKI) - comprehensive system required to provide
public-key encryption and digital signature services. It has three primary
purposes:
243
244 1. publish public keys/certificates
245 2. certify that a key is tied to an individual or entity
246 3. provide verification of the validity of a public key
247
Page 6
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

248 NOTE: PKI functions, or not, based on the TRUST of all of the participants
in the system; remove the trust and the system crashes
249
250 Digital Certificates - assurance mechanism that allows communicating
parties to establish their identity
251
252 X.509 v3 is current format most widely used. Part of the X.500 family of
standards
253
254 Specific information contained in a Digital Certificate:
255
256 a. Version of conformity (v3)
257
258 b. Serial number (unique tracking mechanism from creator)
259
260 c. Signature algorithm used to sign the certificate by the Certificate
Authority (CA)
261
262 d. Issuer Name
263
264 e. Validity Period
265
266 f. Subject's Name (the Distinguished Name, DN, of the owner of the
public key in the certificate)
267
268 g. Subject's Public Key
269
270 Certificate Authorities (CA) - Perform the activities that make the PKI
function, include issuance of certificates and oversight of the
certificate lifecycle. The CA “signs” an entities digital certificate to
certify that the certificate content accurately represents the certificate
owner.
271
272 Types of Certificate Authorities:
273
274 1. Enterprise vs. Stand Alone
275
276 2. Root vs. Subordinate
277
278 Registration Authorities (RA) - assists the CA by verifying the user's
identity PRIOR to the issuance of a certificate. DOES NOT ISSUE
certificate, but facilitate the CAs ability to do so
279
280 Certificate Lifecycle (generation through destruction):
281
282 1. Enrollment - process of obtaining a certificate from a CA by
validating your identity. Will need to provide the CA with a copy of your
PUBLIC KEY once identity is validated to allow CA to issue the digital
certificate on your behalf. Certificate issued is signed by the CA using
it's PRIVATE KEY, certifying that they "TRUST" you and includes a copy of
your PUBLIC KEY.
283
284 2. Verification - the process of checking the validity of an issued
certificate by using the issuing CA's PUBLIC KEY. You must also check to
ensure that the certificate has not been revoked by consulting the CA's
Certificate Revocation List (CRL), or the Online Certificate Status
Protocol (OCSP).
285
Page 7
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

286 3. Revocation - the occasional process that a CA engages in to let the

world know that the certificate is no longer valid. The revocation request
grace period is the maximum response time within which a CA will perform a
revocation. Defined by the Certificate Practice Statement (CPS).
287
288 Asymmetric Key Management - Control over the issuance, revocation,
recovery, distribution, and history of cryptographic keys.
289
290 Kerckhoff’s principle states: “A cryptosystem should be secure even if
everything about the system, except the key, is public knowledge.”
291
292 The key is the true strength of the cryptosystem. The size of the key and
the secrecy of the key are perhaps the two most important elements in a
crypto implementation.
293
294 Data exists in 3 known states both IN and OUTSIDE OF the Cloud....
295
296 1. In Transit (on the wire)
297 2. At Rest (in storage)
298 3. In Use (applications)
299
300 KNOW HOW TO APPLY CRYPTOGRAPHIC PROTECTIONS TO DATA IN EVERY STATE !!! &
Understand the importance of key mangement as part of that process....
301
302 a. at rest (storage) -
303 encryption
304 obfuscation / tokenization
305 archive / dispose / destruct
306 mobile device protection
307 physical media control
308
309 b. in motion (transit) -
310 encryption
311 perimeter security
312 web content filtering
313 network traffic monitoring
314 VPN's
315
316 c. in use (application) -
317 encryption
318 user monitoring
319 workstation restrictions
320 application controls (whitelist / blacklist)
321 data labeling
322
323 Know what a Remote Key Management System (R-KMS) is and why we need one &
who mainatains and controls one when we use it for cloud ... THE CUSTOMER
DOES !!!
324
325
326 Know the difference between a R-KMS & a Client-Side Key Management System
... Where used (SaaS) & who provides ... Cloud Service Provider & who
hosts and controls ... Customer
327
328 What about Access Control? -
329
330 Access control is all about the relationship between users and data. The
goal is to allow authorized access while stopping unauthorized access.
Page 8
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

331 Overall steps:

332
333 1. identify & authenticate
334 2. determine whether access is authorized
335 3. grant or deny access based on user identity
336 4. monitor & record access
337
338
339 I dentify (identity)
340 A uthenticated
341 A uthorize
342 A udit access / accounting (logging of activity)
343
344
345 The 3 categories of controls:
346
347 a. administrative - policy
348 b. technical / logical - software based
349 c. physical - guards / guns / gates
350
351 Control types:
352
353 1. Preventative - attempt to stop unwanted access
354
355 2. Detective - attempt to identify unauthorized access AFTER occurrence
of unauthorized activity
356
357 3. Corrective - modifies environment to return to normal operation AFTER
occurrence of unauthorized activity
358
359 4. Deterrent - attempt to discourage security policy violations. Key
difference between Preventative and Deterrent is that preventative blocks
action while deterrent relies on individual making the right choice
360
361 5. Recovery - attempt to repair or restore after a security violation -
extension of corrective controls, but have more advanced capabilities
362
363 6. Directive - attempt to specify action(s) to ensure compliance with
security policy
364
365 7. Compensating - attempt to provide an alternate control in absence of
primary
366
367
368
369 Authentication Authorization & Accounting (AAA) Protocols - provide
centralized access control when used with remote access systems.
370
371
372 1. RADIUS - provides AAA services between network access servers and an
authentication server. The network access server is the client of the
RADIUS server. RADIUS only encrypts the password exchange, not the rest of
the authentication traffic. Uses UDP 1812.
373
374 2. TACACS+ - Open source solution for TACACS and XTACACS. Separates AAA
processes, allowing them to be hosted separately if necessary. Encrypts
all authentication information, using TCP port 49.
375
Page 9
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

376 3. Diameter - Uses TCP port 3868 or Stream Control Transmission Protocol
(SCTP) port 3868. Supports IPsec and TLS.
377
378
379
380 4 main areas of Access Management are:
381
382 1. Account Provisioning
383 2. Directory Services
384 3. Priviledged Access
385 4. Authorization
386
387
388
389 Data and Media Sanitation - 2 main issues to consider in the Cloud
390
391 1. Data migration between vendors (data lock-in)
392 2. Data removal on a platform (data remanence)
393
394
395 We can EITHER ---
396
397 1. Overwrite (zeroing out)
398 2. Cryptographically Erase / Shred / Shard
399
400
401
402
403 Cloud computing is based on the use of virtualization technology.
404
405 The key component that makes virtualization possible is the use of a
Hypervisor (Virtual Machine Monitor). Types:
406
407 a. Type I - Native or Bare-Metal. Used for Server virtualization
408
409 b. Type II - Hosted on a client O/S
410
411
412
413 Security concerns / challenges in Virtualized environments:
414
415 Container Security (image hygine and security)
416 Data Breaches vs. Data Loss
417 Bad Identity & Access Management
418 Insecure APIs
419 System Vulnerabilities
420 Account Hijacking
421 Malicious Insiders
422 Advanced Persistent Threats (APTs)
423 Lack of Due Dilligence/Due Care
424 Abuse of Services
425 DoS/DDoS
426 Multitenancy & Resource Pooling
427
428
429
430 Security Concerns for IaaS:
431
Page 10
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

432 Multitenancy & Resource Pooling

433 Network
434 VM attacks
435 Virtual Switch attacks
436 DoS/DDoS
437
438
439
440 Security Concerns for PaaS:
441
442 System Isolation
443 User Permissions & Access
444 Malware
445
446
447 Security Concerns for SaaS:
448
449 Web Application Security
450 Data Policies
451 Data Protection/Confidentiality
452
453
454
455
456 Understand Design Principles of Secure Cloud Computing
457
458
459 What is the Cloud Secure Data Lifecycle?
460
461 Data is the single most valuable asset for most organizations, and
depending on the value of the information to their operations, security
controls should be applied accordingly.
462
463 As with systems and other organizational assets, data should have a
defined and managed life cycle across the following key stages:
464
465 • Create - Generation of new data or the modification of existing content
466
467 • Store - Commit data to a storage repository; typically occurs EITHER
as part of Create, or directly after creation
468
469 • Use - Data is viewed, processed, or otherwise used in some sort of
activity
470
471 • Share - Information made accessible to others – users, partners,
customers,
472 etc.
473
474 • Archive - Data leaves active use and enters long-term storage
475
476 • Destroy - Data permanently destroyed using physical or digital means
477
478
479
480 What about BCDR in the Cloud?
481
482 Same but different.... What do I mean?
483
Page 11
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

484 It is about the complexity and roles and responsibilities !!!

485
486
487 Things to consider:
488
489 What does it cost? (Cost Benefit Analysis)
490 How much am I using? (resource pooling and demand management)
491 CapEx vs OpEx
492 Context
493 Ownership vs Control
494
495
496
497 Certification Against Criteria -
498
499 If it cannot be measured – it cannot be managed!
500
501 How can we have confidence, awareness, and assurances that the correct
steps are being taken by ourselves and the cloud provider to ensure that
our data is secured in a manner and way in which we have comfort and peace
of mind?
502
503 Frameworks and standards are the key here !!!
504
505
506 • ISO/IEC 27001 & 27002
507 • NIST SP 800-53 R5
508 • PCI DSS
509 • SOC 1/2/3
510 • Common Criteria (ISO 15408)
511 • FIPS 140-2
512
513
514
515 American Institute of Certified Public Accountants (AICPA) released The
Statement on Standards for Attestation Engagements document 16 (SSAE 16)
to provide a common set of standards to replace older SAS 70 standard & to
give auditors performing assessments a way to standardize their activities.
516
517 Type I - provides a description of the controls provided by the audited
organization and the auditor opinion based on the description, BUT... does
not involve actual testing of controls. A Type I Report is specifically
defined by the SSAE 16 guidance as a “report on a description of a service
organization’s system and the suitability of the design of controls”,
essentially, a determination of if your company’s controls are designed
appropriately. When performing a Type I report, the auditors will test the
design effectiveness of your company’s defined controls by examining a
sample of 1 item per control.
518
519 Type II - covers a minimum period of 6 months and requires testing of
the controls and an opinion from the auditor as to effectiveness based
upon test
520
521
522 What can SSAE-18 report on? - In addition to processes related to
financial statements, an entity’s compliance with certain laws or
regulations, contractual arrangements, or another set of defined
agreed-upon procedures – just about any outsourced service where 3rd party
Page 12
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

validation would be beneficial and add assurance.

523
524
525 Three types of reports:
526
527 NOTE: The trust services principles and criteria are now referred to as
the trust services criteria, and the principles are now referred to as the
trust services categories (not to be confused with the COSO principles).
528
529
530 a. SOC 1 - A SOC 1 Report (Service and Organization Controls Report) is
a report on Controls at a Service Organization which are relevant to user
entities’ internal control over financial reporting. The SOC 1 Report is
what you would have previously considered to be the standard SAS 70,
complete with Type I and Type II reports, but falls under the SSAE 18
guidance (as of May 1, 2017).
531
532
533 b. SOC 2 - The Service and Organization Controls (SOC) 2 Report will be
performed in accordance with AT-C 205 and based upon the Trust Services
Criteria, with the ability to test and report on the design (Type I) and
operating (Type II) effectiveness of a service organization’s controls
(just like SOC 1 / SSAE 18). The SOC 2 report focuses on a business’s
non-financial reporting controls as they relate to security, availability,
processing integrity, confidentiality, and privacy of a system, as opposed
to SOC 1/SSAE 18 which is focused on the financial reporting controls.
534
535 There have been a number of major updates to SOC 2 since its initial
implementation to optimize and enhance the framework’s layout, controls,
flexibility, and usefulness as well as to align it with COSO to further
facilitate their use in an entity-wide engagement.
536
537 Further, beyond attesting to the SOC 2 Criteria and Categories, there are
mappings to other relevant frameworks that can be included and addressed
within a SOC 2 report to make it more flexible and useful to Organizations.
538
539 The Trust Service Criteria, which SOC 2 are based upon, are modeled around
four broad areas: Policies, Communications, Procedures, and Monitoring.
540
541 SOC 2 – Trust Services Categories:
542
543 The SOC 2 criteria are comprised of 5 categories (formerly the SOC 2
principles), security, availability, confidentiality, processing
integrity, and privacy. Each category has a specific set of criteria to
meet with corresponding points of focus:
544
545 1. Security - Information and systems are protected against unauthorized
access, unauthorized disclosure of information, and damage to systems that
could compromise the availability, integrity, confidentiality, and privacy
of information or systems and affect the entity’s ability to meet its
objectives.
546
547 2. Availability - Information and systems are available for operation
and use to meet the entity’s objectives.
548
549 3. Processing integrity - System processing is complete, valid,
accurate, timely, and authorized to meet the entity’s objectives.
550
Page 13
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

551 4. Confidentiality - Information designated as confidential is protected

to meet the entity’s objectives.
552
553 5. Privacy - Personal information is collected, used, retained,
disclosed, and disposed of to meet the entity’s objectives.
554
555
556 c. SOC 3 - The SOC 3 Report, just like SOC 2, is based upon the Trust
Service Principles and performed under AT101, the difference being that a
SOC 3 Report can be freely distributed (general use) and only reports on
if the entity has achieved the Trust Services criteria or not (no
description of tests and results or opinion on description of the system).
The lack of a detailed report requires that a SOC 3 be performed as a Type
I, unlike SOC 1 and SOC 2 where there is a Type II option.
557
558 SOC 3 reports can be issued on one or multiple Trust Services principles
(security, availability, processing integrity, confidentiality and
privacy) and allow the organization to place a seal on their website upon
successful completion.
559
560 The Trust Service Principles were designed with a focus on e-commerce
systems due to the amount of private/confidential/financial information
that flows across them. The most common reports based upon the trust
principles are referred to as WebTrust and SysTrust.
561
562 The SysTrust review encompasses a combination of the following principles:
563
564 1. Security - The system is protected against unauthorized access (both
physical and logical).
565
566 2. Availability - The system is available for operation and use as
committed or agreed.
567
568 3. Processing Integrity - System processing is complete, accurate,
timely, and authorized.
569
570 4. Confidentiality - Information designated as confidential is protected
as committed or agreed.
571
572
573 The WebTrust certification can fall into the following four categories:
574
575 1. WebTrust - The scope of the engagement includes any combination of
the trust principles and criteria.
576
577 2. WebTrust Online Privacy - The scope of the engagement is based upon
the online privacy principle and criteria.
578
579 3. WebTrust Consumer Protection - The scope of the engagement is based
upon the processing integrity and relevant online privacy principles and
criteria.
580
581 4. WebTrust for Certification Authorities - The scope of the engagement
is based upon specific principles and related criteria unique to
certification authorities.
582
583
584
Page 14
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

585 SSAE 18 adds an additional set of requirements to further enhance SSAE 16

standard:
586
587 1. Requires the inclusion of a Complementary Subservice Organization
Controls section (similar to what is currently required for SOC 2).
588
589 2. Requires the performance of a detailed Risk Assessment based on the
control objectives defined in the report.
590
591
592 *** Remember: Although the reporting standard is SSAE 18, the SSAE 16 and
ISAE 3204, are all still considered to be a SOC 1 Report!
593
594
595 Key changes to the standard include:
596
597 Services criteria updated to align with the 17 principles in the COSO
framework, some include:
598
599 a. Demonstrate commitment to integrity and ethical values
600 b. Ensure that board exercises oversight responsibility
601 c. Establish structures, reporting lines, authorities and responsibilities
602 d. Select and develop control activities that mitigate risks
603 e. Select and develop technology controls
604 f. Deploy control activities through policies and procedures
605 g. Perform ongoing or periodic evaluations of internal controls (or a
combination of the two)
606
607 Ability to evaluate control effectiveness in examinations of various
subject matters, in addition to, those over security, availability,
processing integrity, confidentiality, or privacy of information and
systems across:
608
609 1. entire entity
610 2. at a subsidiary, division, or operating unit level
611 3. within a function or system or
612 4. a particular type of information used by the entity
613
614
615 Remember, the trust services principles and criteria are now referred to
as the trust services criteria, and the principles are now referred to as
the trust services categories (not to be confused with the COSO principles).
616
617 Information security requirements have been organized more logically and
broken down into the following areas:
618
619 Logical and physical access controls – the criteria relevant to how an
entity restricts logical and physical access, provides and removes that
access, and prevents unauthorized access to meet the entity’s objectives
addressed by the engagement
620
621 System operations – the criteria relevant to how an entity manages the
operation of systems and detects and mitigates processing deviations,
including logical and physical security deviations, to meet the entity’s
objectives addressed by the engagement
622
623 Change management – the criteria relevant to how an entity identifies
the need for changes, makes the changes using a controlled change
Page 15
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

management process, and prevents unauthorized changes from being made, to

meet the entity’s objectives addressed by the engagement
624
625 The trust services criteria also now address risk management, incident
management, and certain other areas at a more detailed level than in the
past.
626
627
628
629
630 Common Criteria (ISO 15408) - focused on standardizing the general
approach to product evaluation and providing mutual recognition of such
evaluations globally. Introduced protection profiles (PP), which are a
common set of functional and assurance requirements for a category of
vendor products deployed in a particular type of environment. The vendor
product (referred to as a ToE) is then examined against this specific
profile by a third-party evaluation lab using a common evaluation
methodology (CEM).
631
632
633
634 FIPS 140-2:
635
636 The standard provides four distinct levels of security intended to cover a
wide range of potential applications and environments with emphasis on
secure design and implementation of a cryptographic module.
637
638 Relevant specifications include:
639
640 • Cryptographic module specification
641 • Cryptographic module ports
642 • Interfaces, roles, and services
643 • Authentication
644 • Physical security
645 • Operational environment
646 • Cryptographic key management
647 • Design assurance
648 • Controls and mitigating techniques against attacks
649
650
651 4 levels of security are defined:
652
653 Security Level 1: Is the lowest level of security. In order to meet
Level 1 requirements, basic cryptographic module requirements are
specified for at least one approved security function or approved
algorithm. Encryption of a PC board would present an example of a Level 1
rating.
654
655 Security Level 2: Enhances the required physical security mechanisms
listed within Level 1, and requires that capabilities exist to illustrate
evidence of tampering, including locks that are tamper-proof on perimeter
and internal covers to prevent unauthorized physical access to encryption
keys.
656
657 Security Level 3: Looks to develop the basis of Level 1 and Level 2 to
include preventing the intruder from gaining access to information and
data held within the cryptographic module. Additionally, physical security
controls required at Level 3 should move toward detecting access attempts
Page 16
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

and responding appropriately to protect the cryptographic module.

658
659 Security Level 4: Provides the highest level of security, with
mechanisms providing
660 complete protection around the cryptographic module with the intent of
detecting and responding to all unauthorized attempts at physical access.
Upon detection, immediate zeroization of all plaintext Critical Security
Parameters (also known as CSPs – NOT TO BE CONFUSED WITH CLOUD SERVICE
PROVIDERS). Security Level 4 undergoes rigid testing in order to ensure
its adequacy, completeness, and effectiveness.
661
662
663 ============================================================================
==================
664
665 Evaluate Cloud Service Providers & Cloud Architectire Models
666
667 ITIL -
668 • Service Strategy
669 • Service Design
670 • Service Transition
671 • Service Operation
672 • Continual Service Improvement (CSI)
673
674
675 NIST Cloud Technology Roadmap (NIST SP 500-293)
676
677
678
679 Security Architecture Frameworks
680
681
682 SABSA -
683
684 A methodology for developing business-driven, risk and opportunity focused
Security Architectures at both enterprise and solutions level that
traceably support business objectives.
685
686 It is also widely used for Information Assurance Architectures, Risk
Management Frameworks, and to align and seamlessly integrate security and
risk management into IT Architecture methods and frameworks.
687
688 SABSA is comprised of a series of integrated frameworks, models, methods
and processes, used independently or as an holistic integrated enterprise
solution, including:
689
690 Business Requirements Engineering Framework (known as Attributes
Profiling)
691 Risk and Opportunity Management Framework
692 Policy Architecture Framework
693 Security Services-Oriented Architecture Framework
694 Governance Framework
695 Security Domain Framework
696 Through-life Security Service Management & Performance Management
Framework
697
698 =======================================================
699 | Business View | Contextual Architecture |
Page 17
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

700 |======================|================================|
701 | Architect's View | Conceptual Architecture |
702 |======================|================================|
703 | Designer's View | Logical Architecture |
704 |======================|================================|
705 | Constructor's View | Physical Architecture |
706 |======================|================================|
707 | Technician's View | Component Architecture |
708 |======================|================================|
709 | Manager's View | Management Architecture |
710 |======================|================================|
711
712
713
714 Strategy & Planning --> Design --> Implement --> Manage & Measure
715
716
717 ============================================================================
======
718
719 TOGAF Standard, Version 9.2
720
721
722 The TOGAF standard features an extended set of concepts and guidelines to
support the establishment of an integrated hierarchy of architectures
being developed by teams within larger organizations that operate within
an overarching architectural governance model.
723
724 In particular, the following concepts are included:
725
726 Partitioning – a number of techniques and considerations on how to
partition the various architectures within an enterprise.
727
728 Architecture Repository – a logical information model for an
Architecture Repository which can be used as an integrated store for all
outputs created by executing the Architecture Development Method (ADM).
729
730 Capability Framework – a structured definition of the organization,
skills, roles, and responsibilities required to operate an effective
enterprise architecture capability. The TOGAF standard also provides
guidance on a process that can be followed to identify and establish an
appropriate architecture capability.
731
732
733 What is Architecture in the Context of the TOGAF Standard?
734
735 ISO/IEC/IEEE 42010:2011 defines “architecture” as:
736
737 “The fundamental concepts or properties of a system in its environment
embodied in its elements, relationships, and in the principles of its
design and evolution.”
738
739
740 The TOGAF standard embraces ISO/IEC/IEEE 42010:2011 terminology, extending
it to also define a second meaning depending upon the context:
741
742 “The structure of components, their inter-relationships, and the
principles and guidelines governing their design and evolution over time.”
Page 18
CCSP Domain 1 - Cloud Concepts, Architecture, & [Link] 18-08-2021

743
744
745
746 What Kinds of Architecture does the TOGAF Standard Deal with?
747
748 The TOGAF standard covers the development of four related types of
architecture. These four types of architecture are commonly accepted as
subsets of an overall Enterprise Architecture.
749
750
751
752 Business Architecture - The business strategy, governance, organization,
and key business processes.
753
754
755 Data Architecture - The structure of an organization’s logical and
physical data assets and data management resources.
756
757
758 Application Architecture - A blueprint for the individual applications to
be deployed, their interactions, and their relationships to the core
business processes of the organization.
759
760
761 Technology Architecture - The logical software and hardware capabilities
that are required to support the deployment of business, data, and
application services. This includes IT infrastructure, middleware,
networks, communications, processing, and standards.
762
763
764 ============================================================================
======
765
766
767
768
769
770
771
772

Page 19