CCSP Domain 4: Cloud Application Security

Question 1

REST

Answer 1

Cloud applications rely heavily (sometimes exclusively) upon application programming interfaces (APIs).

REpresentation State Transfer (REST) relies on HTTP for transport and supports multiple data formats – JSON and XML are the most widely used – and it allows for caching to support better performance and scalability.

Question 2

SOAP

Answer 2

Cloud applications rely heavily (sometimes exclusively) upon application programming interfaces (APIs).

Simple Object Access Protocol (SOAP) relies on HTTP for transport, supports only the XML data format, and does not allow for caching – ergo, SOAP is often used only when REST is not vaiable.

Question 3

SDLC

Answer 3

Software Development LifeCycle or SDLC is a process framework that does not have a formal definition.

(ISC)2 notes that all interpretations of SDLC include:

Define: generate business requirements

Design: translate the requirements to unambiguous logical and physical specifications

Develop: code the logic and instantiate the physical components to meet the specification

Test: prove / confirm that the specification has been met

(ISC)2 notes that an ‘extended’ model of SDLC includes:

Deploy: go-live with the solution

Maintain: fix bugs, add features, patch the system, etc.

Dispose: retire and decommission the system

Question 4

ISO/IEC 27034-1

Answer 4

Integration of best practices for the specification, selection, and implementation of security controls within the SDLC.

Question 5

ONF and ANF

Answer 5

The Organization Normative Framework (ONF) uses the following template to capture application security controls across the enterprise:

Business context: security policies, standards, and best practices that have been approved for use within the firm

Regulatory context: the laws and regulations that apply to the firm’s applications

Specification: the functional requirements and technology that meets them within the firm

Roles: actors that ‘own’ the application and security controls within the firm

Application Security Control (ASC) Library: all approved controls tagged by or aligned to the threats they address

The Application Normative Framework (ANF) uses this same template but localizes it to a specific application.

ANF is one to one. ONF is one to many.

Question 6

Software Development Methods

Waterfall
Verification and Validation
Prototype
Iterate and Improve
Spiral
Agile

Answer 6

Per (ISC)2 materials:

Waterfall: all elements of the project are planned prior to development – a final and complete product is planned for then developed, tested, and delivered to production

Verification and Validation: as above, with frequent milestones for testing and validation of progress

Prototype: a minimally viable product is delivered for use and feedback, then a complete product is planned, developed, tested, and delivered

Iterate and Improve: the whole is broken into units with the units delivered in sequence, as units go-live, they and the whole are evaluated with improvements flowing forward into the next deliverable unit

Spiral: iterative with repeating phases – e.g. plan, analyze, develop, evaluate… plan

Agile: combines Iterate and Improve with Spiral

Question 7

STRIDE

Answer 7

A mnemonic for:

Spoofing Identity: protections against an attacker assuming the identity of a legitimate user – e.g. steals the username + password, hijacks the user session, etc.

Tampering with Data: protections against injection and other methods of data alteration or destruction

Repudiation: creates a chain of custody for transactions sufficient to prove / disprove an action claimed by a user

Information Disclosure: protects against sharing data with unintended or unauthorized parties

Denial of Service: protects against floods of input designed to degrade or down a system or service.

Elevation of Privileges: protects against an attacker moving to a higher privilege account – e.g. requires that Admins use 2FA to access the system, etc.

Question 8

Injection, OWASP

Answer 8

Attacker inputs commands and arbitrary data via input and data fields with the intent of having the application or system execute the code as part of its normal processing thereby exposing data to the attacker.

e.g. : SQL query is input to field, executed by the db, and returns output to the attacker

Solution: input validation and sanitization (like escaping high risk characters) by the application or system prior to processing by the data store.

Question 9

Broken Authentication, OWASP

Answer 9

Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

e.g. credential stuffing, session timeouts overly permissive, etc.

Solution: Multi-factor authentication, check for / do not allow weak passwords, limit failed login attempts, don’t ship with default administrative credentials, harden registration, credential recovery, and API pathways, use server-side, secure, built-in session manager that generates new random session ID with high entropy after login.

Question 10

Broken Access Control, OWASP

Answer 10

Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

e.g. horizontal permissions issue: attacker logs-on to a service then changes the primary key in a URL thereby gaining access to another authorized account; vertical permissions issue: page source code references a cgi-bin, attacker modifies URL to inject to that cgi-bin, and gets an output response

Solution: enforce access controls with server-side code or server-less API where the attacker cannot modify the access control check or metadata.

Question 11

Security Misconfiguration, OWASP

Answer 11

Security misconfiguration is the most commonly seen issue. Causes include insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

e.g. default configuration is not secure or available security options are not utilized or are not properly set… a bit of a catch-all for standard good options not taken.

Solution: utilize secure installation process to provide minimal platforms (least privilege) free from unnecessary features, provision and de-provision should support rapid roll out of new, secure / patched, environment, segmented architectures to limit contagion in event of an attack, and automated audit of state (configurations, settings, applications) to ensure effectiveness.

Question 12

Cross-Site Scripting (XSS), OWASP

Answer 12

XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or, updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

e.g. attacker comments on an article with a javascript, next user to access the page runs the javascript.

Solution: separate untrusted data from active browser content – escape untrusted inputs, application of the OWASP Cheat Sheet for XSS Prevention, etc.

Question 13

Insecure Deserialization, OWASP

Answer 13

Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

Serialization translates binary into a string to enable a larger number of transfer protocols; if an application or API deserializes without checking integrity or authorization it is susceptible to this attack.

Solution: The only safe architectural pattern is not to accept serialized objects from untrusted sources or to use serialization mediums that only permit primitive data types.

Question 14

Using Components with Known Vulnerabilities, OWASP

Answer 14

Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

Solution: Patch management, inventory and assessment of components to ensure that they are current (well maintained) and free from defects

Question 15

Insufficient Logging and Monitoring, OWASP

Answer 15

Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident.

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

Solution: monitor core and critical events – core: login, access control failures, server-side input validation failures should be logged as should any ‘high value’ transactions specific to the context of your business.

Question 16

Continuous Security Validation

Answer 16

In DevSecOps, continuous security validation is an approved continuous improvement / continuous delivery process that can be audited to ensure conformity with security standards; this includes, static code analysis, automated penetration testing, and infrastructure validation.

Continuous security validation, as an artifact, illustrates the DevSecOps focus on automation of security functions.

Question 17

LAMP

Answer 17

Linux, Apache, MySQL, and PHP

One of the three most common cloud application server-side stacks.

Question 18

WISA

Answer 18

Windows, IIS, SQL Server, and ASP.NET

One of the three most common cloud application server-side stacks.

Question 19

Java web application stack

Answer 19

Linux or Solaris, Tomcat, MySQL, and JSP

One of the three most common cloud application server-side stacks.

Question 20

Data Breaches, CSA Treacherous Twelve

Answer 20

Any vulnerability in a application can lead to a data breach for that application as well as expose other applications hosted within the same cloud environment due to multitenancy, especially if the cloud provider does not have appropriate segmentation and isolation between tenants.

The affect of this threat is increased if the hypervisor or management plane is the locus of the compromise.

Question 21

Insufficient Identity, Credential, and Access Management

CSA Treacherous Twelve

Answer 21

The IAM implementation that a cloud environment or application uses is crucial to operations and features such as federation.

Without proper and strong access management and identity systems in place, a cloud environment and applications are exposed to many other threats on this list – in particular, data breaches and malicious insiders.

Question 22

Insecure Interfaces and APIs, CSA Treacherous Twelve

Answer 22

Cloud environments and many cloud-based applications rely heavily on APIs for automation and operations; insecure APIs can lead to exposure and threat at both the cloud infrastructure and application levels.

Question 23

System Vulnerabilities, CSA Treacherous Twelve

Answer 23

Any bugs found in the application-hosting framework, including unpatched elements of the operating system, the underlying virtual environment, programming libraries and runtime environments, are a potential vulnerability for the system.

Question 24

Account Hijacking, CSA Treacherous Twelve

Answer 24

Especially in instances where account sharing is permitted (! bad !), accounts can be exposed and used by those wanting to compromise a system. Accounts should always be issued to an individual for their use only, with multi-factor authentication systems in place to prevent another user from using an account, even if they do obtain the credentials for it.

Question 25

Malicious Insiders, CSA Treacherous Twelve

Answer 25

Any user who has legitimate access to a system or resources can use that access for unauthorized purposes. Active monitoring and auditing systems are needed at all times with sensitive systems and data to counter and catch unauthorized access and use.

Question 26

Advanced Persistent Threats, CSA Treacherous Twelve

Answer 26

Advanced persistent threats occur any time a long-term program or malware is introduced into an environment to operate or steal data. In most cases, user education and training are effective countermeasures because most threats of this type require some degree of user action or intervention to allow the exploit to enter the system initially or to continue to operate.

Question 27

Data Loss, CSA Treacherous Twelve

Answer 27

The deletion of data can occur by accident, via authorized users and processes, or as the result of a malicious insider or external compromise.

Within a cloud environment, data loss can come from the purposeful or accidental deletion of backups, a natural disaster or a physical event that causes actual loss of hardware systems that house the data, or when the key sets of an encrypted system are lost or destroyed.

Question 28

Insufficient Due Diligence, CSA Treacherous Twelve

Answer 28

With any system or application, due diligence on the part of management, security personnel, and even users is required for optimal security and protection. Through active training and strong policies with enforcement mechanisms, many of the typical threats can be avoided and countered.

Question 29

Abuse and Nefarious Use of Cloud Services,

CSA Treacherous Twelve

Answer 29

Without proper application security controls in place, a malicious actor could infiltrate cloud applications or resources and use them to then attack other services or applications.

Question 30

Denial of Service, CSA Treacherous Twelve

Answer 30

Flooding enormous amounts of traffic into a cloud environment has the potential to make an application slow or inaccessible. The impact might even be felt and experienced by all tenants hosted by the same cloud provider.

Question 31

Shared Technology Issues, CSA Treacherous Twelve

Answer 31

With multitenancy and resource pooling, all cloud customers within a cloud provider use the same set of resources and technologies. By having technologies in place, including software applications, to serve a large number of customers, it is possible that not all components will be as secure as desired for all applications. This puts more of the onus on each cloud provider to layer on additional security and monitoring systems for their own applications.

Question 32

DREAD

Answer 32

A risk calculation method that generates a score of 0 (low) to 10 (high):

DREAD = (Damage + Reproducibility + Exploitability + Affected Users + Discoverability) / 5

Damage: 0, no damage or loss of value
10, total loss of data / application / hardware

Reproducibility: 0, nearly impossible to reproduce (0-day)
10, an exploit that is like a bug / fault

Exploitability: 0, extensive knowledge required
10, no specific knowledge required

Affected Users: 0, no users affected
10, all users affected

Discoverability: 0, impossible to detect / discover
10, immediately noticeable to the user

Question 33

DAST, Cloud SDLC

Answer 33

Dynamic application security testing (DAST) is black-box testing of an application. DAST is run against live systems, and those running it do not have the benefit of special knowledge of the system.

DAST is generally used in conjunction with SAST to combine outside and inside points of view to arrive at a comprehensive assessment of application vulnerabilities.

Question 34

Penetration Testing, Cloud SDLC

Answer 34

Penetration testing is typically black-box (no special knowledge of the application) and utilizes the same tools and techniques used by attackers

Question 35

RASP, Cloud SDLC

Answer 35

Runtime application self-protection (RASP) is typically run against systems that have the ability to tune and focus their security measures based on actual environmental variables and particular attack methods being used against them.

Question 36

SAST, Cloud SDLC

Answer 36

Static Application Security Testing (SAST) is white-box testing – i.e. the tester knows the application and has access to source code; SAST occurs off-line (i.e. non-production) and is particularly good at catching programming errors and vulnerabilities such as SQL injection and XXS.

Question 37

Vulnerability Scanning, Cloud SDLC

Answer 37

A scan run by system owners or partners that uses known attacks and methodologies to verify that a system is properly hardened against them.

Question 38

Insecure Direct Object References, OWASP

Answer 38

A direct object reference occurs when a developer exposes a reference to an internal implementation object (such as a file, directory or database key); without access control checks or other protections, attackers can manipulate these references to gain unauthorized access to data.



Solution: Check access to ensure that the user and the object belong together, and, use indirect object references (tokens) or explicit authorization only.

Question 39

Missing Function Level Access Control, OWASP

Answer 39

Most web applications don’t display links to unauthorized functions, but this “presentation layer access control” doesn’t actually provide protection — you must implement checks in the controller or business logic.



This vulnerability may be accessed within an authenticated session or by an unauthorized user. 



Solution: Verify every application function and ensure that navigation does not lead to unauthorized functions, that server side authentication or authorization checks are ON, and that these checks do not solely rely upon data provided by the User / Attacker.

Question 40

Cross-Site Request Forgery (CSRF or XSRF), OWASP

Answer 40

A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request (including the victim’s session cookie and any other automatically included authentication information) to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests that the vulnerable application thinks are legitimate requests from the victim.



Solution: Include a unique and unpredictable token in a hidden field — this sends the value in the body of the HTTP request, not the URL — or, require the user to re-authenticate / enter CAPTCHA.



Note that CSRF requires the victim to be ‘logged-on’ / authenticated at the time of the attack.

Question 41

Unvalidated Redirects and Forwards, OWASP

Answer 41

Web applications frequently redirect and forward users to other pages and websites using untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites or use forwards to access unauthorized pages.



Solution: Avoid using redirects and forwards; or, if used, don’t involve user parameters to calculate the destination; or, if user parameters are required, validate input and authorize the user.