Cloud Application Security

CCSP: Domain 4
CLOUD APPLICATION SECURITY

DOMAIN 4 CLOUD APPLICATION SECURITY

Determining Data Sensitivity
Security Responsibilities Across Models
The Software Development Lifecycle
OWASP Top Ten Vulnerabilities
IAM and Federated identity management
Application Security Testing

DETERMINING DATA SENSITIVITY

Six key questions in relation to determining data sensitivity. What would the impact be if:
Information was widely distributed
An employee of cloud provider accessed the application
The process was manipulated by an outsider
The process failed to provide the expected result
The information was unexpectedly changed
The application or information was unavailable for a period of time

SECURITY RESPONSIBILITIES ACROSS MODELS

THE SDLC (SOFTWARE DEVELOPMENT LIFECYCLE) FOR THE CLOUD

Planning and Requirements analysis: All business requirements should be defined and risks should be identified
Defining: Clearly defines the requirements through a requirement specification document
Designing: Specifies hardware and system requirements and helps define overall architecture
Developing: Work is divided into modules and the actual coding starts
Testing: Code is tested against requirements: Unit testing, integration testing, system testing and user acceptance testing
Maintenance:  Continuous monitoring and updates as needed

VULNERABILITY DATABASES AND RESOURCES

OWASP (Open Web Application Security Project) Top Ten
CVE (Common Vulnerabilities and Exposures)
CWE (Common Weakness Enumeration)
NVD (National Vulnerability Database)
US CERT (Computer Emergency Response Team) Vulnerability Database

OWASP (OPEN WEB APPLICATION SECURITY PROJECT) TOP TEN

OWASP is an international non-profit organization
OWASP (Open Web Application Security Project) Top Ten
Offers a broad consensus on the most common security flaws/exploits
Designed to raise awareness and the stress the need for security in web-based applications

https://www.owasp.org/index.php/About_OWASP

OWASP TOP TEN 2013

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=OWASP_Top_10_for_2013

1. CODE INJECTION
Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization

2. BROKEN AUTHENTICATION & SESSION MANAGEMENT
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities

3. XSS (CROSS SITE SCRIPTING)
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. 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

4. INSECURE DIRECT OBJECT REFERENCES

Defined as an unauthorized user or process which can invoke the internal functionality of the software by manipulating parameters and other object values that directly reference this functionality. Issues resulting include:
Data disclosure
Privilege escalation
Authentication and authorization checks bypass
Restricted resource access

5. SECURITY MISCONFIGURATIONS

Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date

6. SENSITIVE DATA EXPOSURE

Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser
Primary reasons for sensitive data exposure:
Insufficient data‐in‐transit protection
Insufficient data‐at‐rest protection and
Electronic social engineering

7. MISSING FUNCTION LEVEL ACCESS CONTROL

Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization
Failure to restrict access to privileged functionalities or URLs. Web pages that provide administrative functionality are the primary targets for such brute force attacks Mitigation: Role Based Access Control (RBAC) of functions and URLs that denies access by default

8. CROSS SITE REQUEST FORGERY (CSRF)

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 the vulnerable application thinks are legitimate requests from the victim

CSRF MITIGATION STRATEGIES

Do not save username/password in the browser.
Do not check the “remember me” option in websites.
Do not use the same browser to surf the Internet and access sensitive websites at the same time, if you are accessing both from the same machine.
Read standard emails in plain text.
Explicitly log off after using a web application.
Use client‐side browser extensions that mitigate CSRF attacks.

DEVELOPER STRATEGIES TO MITIGATE CSRF

Implement the software to use a unique session specific token (called a nonce) that is generated in a random, non‐predictable, non‐guessable and/or sequential manner.
CAPTCHAs can be used to establish specific token identifiers per session.
The uniqueness of session tokens is to be validated on the server side and not be solely dependent on client based validation.
Use POST methods instead of GET requests for sensitive data transactions and privileged and state change transactions, along with randomized session identifier generation and usage

9. KNOWN VULNERABLE COMPONENT USAGE

Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts
Deprecated, insecure and banned APIs

10.  NON VALIDATED REDIRECTS AND FORWARDS

Web applications frequently redirect and forward users to other pages and websites, and use 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

THREAT MODELING

Identify Security Objectives
Legislative Drivers
Contractual Requirements
Alignment with Business Objectives
CIA Triad
Tools for Threat Modelling
Data Flow Diagrams
Use/Misuse Cases

THREAT MODELLING:  DATA FLOW DIAGRAMS

Blue circles are data transformations (processing). Arrows are data flows. The “Student database” is a data store

USE/MISUSE CASES

https://www.owasp.org/index.php/Application_Threat_Modeling

THREAT MODELLING: STRIDE

ThreatMitigation

SpoofingAuthentication

TamperingIntegrity Verification (Message Digests/CRCs)

RepudiationNon-Repudiation (Digital Signatures, Keys)

Information DisclosureConfidentiality Through Encryption

Denial of ServiceHigh Availability/Redundancy/Fault Tolerance

Escalation of PrivilegeAuthorization

RISKS IN DESIGN

Code Reuse
Flaws vs. Bugs
Flaw: Inherent fault with the design of code
Bug: Implementation fault
Open vs. Closed Design

CONTROLS EVALUATION

Efficacy of Controls
Economy of Mechanism
Cost/Benefit Analysis
Psychological Acceptability

SUPPLEMENTAL SECURITY DEVICES

WAF Web Application Firewall is Layer 7 firewall that can understand HTTP traffic and help prevent DoS attacks
DAM Database Activity Monitoring is a layer 7 monitoring device that understands SQL commands and can limit code injection
XML Gateways transform how services and sensitive data are exposed as APIs to developers and users and can implement DLPs, antivirus and anti-malware
Firewalls can be configured across the SaaS, PaaS and IaaS
API Gateways filter APIs and can implement access control, rate limiting, logging, metrics and filtering

APPLICATION SECURITY TESTING

SAST Static Application Security Testing: Whitebox test used to determine structure and logic and to detect coding errors without executing the code. Should be done early in the lifecycle
DAST Dynamic Application Security Testing is used with applications in their running state and is considered a black-box test
RASP Runtime Application Self Protection: enables applications to protect themselves by identifying and blocking attacks in real time. Unlike firewalls, which rely solely on network data to work, RASP leverages the application’s intrinsic knowledge of itself to accurately differentiate attacks from legitimate traffic, stopping only malicious traffic