Domain 4

Cloud Application Security

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
‫ مثال يبقي‬20 ‫ ولو تخطيت الـــ‬rate or scale from 1 to 5 for example ‫ واال ال محتاج احط‬security ‫عشان تقدر تحدد هل محتاج‬
my data is sensitive and start to determine the suitable countermeasure to protect it

Understanding API’s

Best practice to transfer data is using rest because it is simpler and more scalable and give
high performance and support many different formats.

Common pitfalls of Cloud Security Application Deployment

 1) On-Premises Doesn’t always transfer:
• Current configurations and applications may be hard to replicate on or through cloud services
or present performance and functionality may not be transferable.
• they were not developed with cloud-based services in mind.
• not all applications can be forklifted to the cloud. ‫يعني تتنقل مرة واحدة ع الكالود‬
2) Not all Apps are cloud-Ready:
• Many Applications compounded by the requirement for such systems to be developed, tested,
and assessed in on-premises or traditional environments.
• Many high-end applications come with distinct security and regulatory restrictions or rely on
legacy coding projects, many of which may have been developed using COBOL.
3) Lack of training and awareness:
• developers have become accustomed to working with Microsoft.NET, SQL Server, Java, and other
traditional development techniques.
• When cloud-based environments are required or are requested by the organization, this may
introduce challenges (particularly if it is a platform or system with which developers are unfamiliar).
4) Lack of documentations and guide
• Although many providers are continuing to enhance levels of available documentation, the most
up-to-date guidance may not always be available, particularly for new releases and updates.
• ISO/IEC 12207 represent processes that establish a lifecycle for software and provide a mode for
the development, acquisition, and configuration of software systems.
5) Complexities of integration
• Integrating new applications with existing ones which is very challenging.
• From a troubleshooting perspective, it can prove difficult to track or collect events and transactions
across interdependent or underlying components.
• API should be used.
6) Overarching challenges
Developers must keep in mind two key risks associated with applications
• Multitenancy
• Third-party administrators
• His/her Responsibility

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 architecture define
overall
• Developing: Work is divided into modules and the actual coding starts
• Testing: Code is tested against requirements: Unit testing, integration testing and user acceptance
and system testing
• Maintenance: Continuous monitoring and updates as needed
Secure Operations Phase
From a security perspective
• Once the application has been implemented using software development lifecycle principles, the
application enters a secure operations phase.
• Puppet.
• Chef.
• Dynamic analysis.
• Vulnerability assessments and penetration testing
• Activity monitoring
• Layer-7 firewalls (such as web application firewalls)
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)
• OWASP is an international non-profit organization
• OWASP 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

OWASP TOP TEN 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
to overcome this issue (Validate input and skip output) accept only data with format and size and type
you already intended to be , skip some operations or keywords like (select- delete - alter) ‫الكلمات اللي‬
‫ممكن تعملي مشكلة‬
2) Broken authentication
• 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
To overcome it use Proper validation and skipping
4) Insecure direct object reference
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 Misconfiguration
• 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 xwell 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
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
• 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
• 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) Using known vulnerable components
• 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)Unvalidated 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
Threat modeling is performed once An application design is created.
• CIA Triad
• Tools for Threat
• Modeling
• Data Flow Diagrams
• Use/Misuse Cases
Data Flow Diagrams
• Blue circles are data transformations
(processing).
• Arrows are data flows.
• The "Student database" is a data store

USE/MISUSE CASES
 Threat Modeling: Stride

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: White box test used to determine structure and logic and to
detect coding errors without executing the code. Should be done early in the lifecycle.
• SAST can be used to find XSS errors, SQL injection, buffer overflows, unhandled error conditions, and
potential backdoors.
• DAST Dynamic Application Security Testing is used with applications in their running state
and is considered a black-box test.
• Static and dynamic application tests work together to enhance the reliability of organizations creating
and using secure applications
• 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
• Prevoty Application monitoring and protection
• Immunio Real-time web application security & protection
• Fortify Application Defender - HP
• Veracode Runtime Protection
• Arxan Application Protection - IBM
• Contrast Protect
• Waratek Runtime Application Self Protection
• DIGIPASS for Apps – RASP

OWSAP Recommendations for testing

• 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