CCSP Domain 4 - Cloud Software Assurance MindMap

Introduction

Hey, I’m Rob Witcher from Destination Certification, and I’m here to help you pass the CCSP exam. We are going to go through a review of the major topics related to common vulnerabilities, threat modeling, and verified secure software in Domain 4, to understand how they relate to one another. Understanding the links will help to guide your studies.

This is the fourth of seven videos for Domain 4. I have included links to the other MindMap videos in the description below. These MindMaps are a teensy part of our complete CCSP MasterClass.

Common Vulnerabilities & Threat Modeling

The radical differences involved in cloud architectures bring a range of new vulnerabilities, but we also still deal with many of the same old vulnerabilities that affect traditional environments.

Cross-Site Scripting (XSS)

We’ll start with cross-site scripting. These are attacks in which malicious scripts are injected into otherwise benign and trusted web sites and a visitor's browser will download and execute the attacker's script. Essentially allowing an attacker to run code on victim’s machines which allows the attacker to do things like exfiltrate data. There are three major flavors of XSS.

Stored (Persistent)

We’ll start with stored cross-site scripting. An attacker discovers a vulnerable website, and injects their code into the web application in such a way that the code is stored on the server and then displayed to every subsequent user that visits the webpage. This can be achieved by the attacker simply entering a comment on a website that has some sort of forum or comments section. Rather than the attacker adding some pithy comment about how someone else’s opinion on the Internet is wrong, they enter JavaScript code in the comment field and hit submit. The attacker’s comment, the code, is stored on the server, and every subsequent user’s browser is going to download the HTML page with the JavaScript code embedded in it, parse the page, and execute the malicious JavaScript code. Stored XSS is persistent–every subsequent user will download and execute the injected code.

Reflected (Most common)

Reflected cross-site scripting works a little differently. The malicious code from an attacker is only reflected back to one specific user. Here’s how this can work: an attacker sends the victim an email, perhaps as a phishing attack, and contained within the email is a link, a URL (Universal Resource Locator), and the URL contains some malicious JavaScript code. The user clicks on the URL sending the request to the server. The server then displays a webpage to the user that contains the malicious code from the URL–effectively reflecting the malicious code back to the user, and the user’s browser dutifully executes the malicious code. That’s a wildly oversimplified explanation. Let me know in the comments if you want me to create a deep-dive video on this.

You should remember that reflected XSS is the most common form of XSS

DOM

DOM, which stands for Document Object Model, is a much more technically complicated way of achieving XSS and it is rare. Accordingly, I wouldn’t worry about it for the exam.

Cross Site Request Forgery (CSRF)

Ok, the next common web-based vulnerability is cross-site request forgery (CSRF). This is where an attacker forces or tricks a user into executing unwanted actions on a web application in which the user is currently authenticated. Effectively allowing an attacker to execute authorized commands on a server. Again, that's a rather wildly oversimplified explanation.

SQL Injection

Next up is SQL injection. SQL–Structured Query Language–is the language used to communicate with databases. A web application can send SQL commands to a back-end database to verify if a user’s username and password are valid, to store new data in the database, or to retrieve data from the database. The database is where the web application stores a lot of its data, and a user should not be able to directly command and control the back-end database.

In SQL injection attacks, that is exactly what is happening. An attacker sends some SQL code to the web server, and then the web server passes that SQL code on to the database allowing the attacker to control the database. Not good.

Input Validation

How do we prevent XSS or SQL injection attacks? Input validation. The web application should never allow SQL code from a user to be passed directly to the database. The web server must validate all input: sanitize the input by removing special characters, or escaping them.

Here is a big hint for the exam. You will likely see very technical questions on SQL injection or XSS, and equally technical answers to choose from. But if you boil them down, the answer you are almost always looking for is that the user’s input has been validated in some way–sanitized.

Insecure Direct Object Reference

An insecure direct object reference occurs when an application allows access to a resource without properly verifying authorization. Let’s say you’re logged into your legitimate account on an ecommerce website where the URL indicates that you are customer 1001. If you changed it to 1002 and the website gave you access to customer 1002’s account, that’s an insecure direct object reference vulnerability. The website is allowing you to access the other user’s account without verifying whether you are authorized to do so.

Buffer Overflows

Parameter / bounds checking

To protect against buffer overflows, code should always be written to perform parameter or bounds checking, to never allow a chunk of data to be written to a buffer that is larger than the buffer. 

Threat Modeling

ATASM

STRIDE

PASTA

PASTA is another type of thread model, which stands for the Process for Attack Simulation and Threat Analysis.

PASTA is the super time-consuming, super in-depth methodology for threat modeling. PASTA is a seven-step, risk-centric methodology. PASTA provides way more useful results and it takes into account the business value of assets, compliance issues, and provides a strategic threat analysis. So STRIDE is the quick and easy way of systematically identifying threats and PASTA is the super time-consuming method that produces way more useful and nuanced results. 

DREAD

The final threat modeling methodology you should know about is DREAD. DREAD is not used to identify threats, rather it is used to prioritize a list of threats that have already been identified. STRIDE and DREAD are often used together. STRIDE is used to identify the threats, and DREAD is used to prioritize the identified threats. 

Verified Secure Software

Moving on to the next major section of this MindMap: verified secure software. We always want our software to be reliable and of the highest quality. In the cloud, we use a lot of third-party software, so we’re going to discuss a few key software aspects we need to look at to ensure we have reliable and secure systems in the cloud. 

Application Programming Interfaces (APIs)

APIs are application programming interfaces, which are used extensively in the cloud. They are used by cloud providers to control their services, by customers to access the services, and in many other ways. The security of APIs is absolutely critical in the cloud. There are two major API protocols that you need to know about. 

REST

Rest stands for Representational State Transfer, and it’s a newer, lighter weight protocol for APIs. 

Simple, Fast, Most Widely Used

It’s simple, fast, and widely used. Basically you always want to use REST whenever you can. It’s simpler, easier and faster. 

SOAP

SOAP stands for Service Oriented Architecture Protocol. It’s an older protocol that was developed by MIcrosoft. 

More capabilities, More complexity

SOAP is more complex, and more difficult to use than REST, but it does provide some very useful additional features. SOAP is typically used for enterprise-level services where security, transaction compliance, and formal contracts are critical (for example, banking and payment gateways).

Approved APIs

Before an organization uses an API, it should go through an approval process to make sure that it meets the security and functional requirements of the organization.

Software / API Supply chain management

Using an API can introduce new risks to an organization. Because of these risks, we should consider APIs from a supply-chain management perspective. We need to look at what benefits they can bring to the organization, as well as what the risks are. If the risks are low, or they can be mitigated, then we can use the API. If the risks outweigh the benefits, then we should look at other options. When we select and use an API we need to make sure the risks associated with the API have been identified and appropriate mitigating controls have been put in place. This is essentially the idea of API supply-chain management. 

That’s all for our overview of common vulnerabilities, threat modeling, and verified secure software within Domain 4. We’ve covered the most critical concepts you need to know for the exam.

If you found this video helpful you can hit the thumbs up button and if you want to be notified when we release additional videos in this MindMap series, then please subscribe and hit the bell icon to get notifications.

I will provide links to the other MindMap videos in the description below.

Thanks very much for watching! And all the best in your studies!