Cloud Application Security: A Deep Dive into CCSP Domain 4

There are many different methodologies and models you can use for secure software development. The ideal one is dependent on what you are trying to achieve and what your priorities are. In the subsequent sections, we will be discussing two of the most common choices, waterfall and Agile.

Immutable infrastructure is infrastructure that can’t be changed. Immutable infrastructure can include virtualized components such as boundary firewalls, routers, switches, and various workloads. These immutable workloads include virtual machines and containers that have been configured so that no changes are possible. Both immutable infrastructure and immutable workloads are often created by building systems that don’t allow changes, or by enforcing automated processes that overwrite any unauthorized changes.

If we wanted to deploy a server as an immutable VM (virtual machine), we would take the server configuration files and source code and build them into an image. We would then store that image in the repository, as seen in the diagram above.

Once it has been built, it would need to be tested. Upon completion of testing, it’s termed a master image, which is also stored in the repository. You can then deploy copies of the master image into production. If these immutable servers required changes, you would have to rebuild an image with the appropriate changes, put it into testing, deploy it, and then throw out the old immutable VM.

Infrastructure as code allows us to deploy infrastructure using software commands. Instead of using interactive configuration tools and commands, IaC allows the usage of machine-readable definition files to make changes to architectures and their configurations. Since cloud customers are using virtualized forms of their provider’s underlying physical resources, customers can configure their infrastructure through code. We use configuration files to specify the details.

With just a few lines of code, a cloud customer can launch the infrastructure they need. When they need to instantiate a new load balancer or create a new VM, all the customer needs to do is send API calls, because it’s all virtualized. This infrastructure can be made immutable, which is a good way to lock it down and secure your environment.

DevSecOps is based on the DevOps approach, which involves integrating software development (Dev) and IT operations (Ops). This can make the software development lifecycle more responsive, resulting in the delivery of quality software at a faster pace, with more frequent releases. DevSecOps brings in security (Sec) as well, decentralizing security practices and making delivery teams responsible for security controls in their software. DevSecOps brings security practices into the entirety of the software development lifecycle, relying heavily on automation to secure code from the initial stages all the way through to testing, deployment, and delivery. The following diagram provides a visualization of the DevOps approach, while the DevSecOps manifesto is included in the table.

CI/CD stands for continuous integration, continuous delivery, although sometimes sources switch out “delivery” for “deployment”. Continuous integration involves automating many of the steps for committing code to a repository, as well as automating much of the testing. This allows code changes to be frequently integrated into the shared source code and ensures that a bunch of testing gets done easily.

Continuous delivery also involves automating the integration and testing of code changes, but it includes delivery as well, automating the release of these validated changes into the repository. Continuous deployment takes things a step further and automatically releases the code changes into production so that they can be used by customers. With continuous deployment, code changes can be automatically put into production without further human intervention, as long as they pass through all of the testing and there are no issues. If there is an error in any of these steps, the changes will get sent back to the developer. The diagram highlights how these three processes overlap:

Now that we have outlined the software development life cycle, we can dive into some of the security considerations in more depth.

he huge contrast between traditional architectures and the cloud means that there are a range of cloud-specific risks. Some of these include:

• Due to the shared responsibility model, cloud customers will share both control and responsibility with their provider.
• Under the cloud model, customers generally have less visibility.
• The management plane offers centralized control that isn’t available under traditional architectures. However, because it has so much access and power, it must be carefully secured.
• Public clouds have multitenancy. Although cloud providers should enforce logical isolation between tenants, this is still a risk that doesn’t exist in on-premises infrastructure.

Threat modeling involves systematically identifying, enumerating and prioritizing the threats that relate to an asset. This allows us to assess the risk to a given asset, as shown in the diagram below. There are many different threats that can impact assets with wide-ranging value and sensitivity. We need a systematic way to identify and prioritize threats so that we can effectively allocate our limited resources toward mitigation.

The components of risks

The STRIDE model helps you to identify and categorize threats, while the DREAD model aims to help you determine the severity of a threat:

The Process for Attack Simulation and Threat Analysis (PASTA) model is a more recent development. Its steps are outlined in the following table:

The ATASM model is a high-level process for threat modelling highlighted in the following table:

We introduced many of the most common vulnerabilities when we discussed the OWASP Top 10 and the SANS Top 25 in 4.1 Common Cloud Vulnerabilities. Now we will delve into some of the most important ones in more depth.

There are three major types of cross-site scripting (XSS):

Stored XSS Attack

Reflected XSS Attack

The core of a CSRF attack is illustrated in the following diagram. It involves:

• An attacker tailoring a link that can direct a user into submitting an unwanted action.
• The attacker sending a link to the victim.
• The victim clicking on the link which sends a request to the website.
• The website processing the request. It assumes that the request is legitimate because it originates from the victim’s web browser. However, the victim must be logged into their account at the time in order for this to work.

Below are the important differences between XSS and CSRF attacks:

Insecure direct object reference vulnerabilities occur when applications do not check authentication against user-supplied inputs. The following image shows an example of a malicious user exploiting an insecure direct object reference vulnerability on a website.

To comprehend SQL injection, you first need an understanding of Structured Query Language (SQL), which is a language used for communicating with databases. SQL injection is a method of attack that utilizes SQL commands and can be used for modification, corruption, insertion, or deletion of data in a database.

The image above illustrates what SQL injection looks like. In this case, imagine a webserver with a database residing behind it. The website associated with this configuration is a dynamic website, meaning that web pages can be created dynamically using data from the database, based upon user requests and interaction with the website.

Due to the dynamic nature of these websites, a persistent connection to the database is required, but a web user should never be able to directly interact with the back-end database. However, SQL injection makes this possible.

A simple login screen is used so that when a person enters their username and password, the database will be queried for the corresponding information, and if it is valid, the user should be authenticated. Using SQL injection, however, neither a correct nor incorrect username is entered into the “Username” field. Instead, SQL code is entered as shown in the image above.

The first part of this code—aaa—is just text and could be replaced by any other text, as can the bbb entry in the password field. However, everything else following the aaa in the username field (‘ OR 1=1 --) constitutes the SQL injection string.

Once this information is entered, the web server will formulate the request into SQL code and send it to the database server, asking if this username and password exist in the database. The first SQL statement below the login box shows how this request will be perceived by the back-end SQL database. Because of the apostrophe (‘) at the end of aaa, the database server treats aaa as the end of the username and then searches for the username aaa, which probably does not exist. Next, OR 1=1 is treated as an SQL statement, which when analyzed yields “true.” In essence the interpreter executes a logical OR query, which is true if either of the conditions accompanying it are considered true. aaa doesn’t exist (resulting in a false state); however, 1 always equals 1, so that returns a true state. Finally, within SQL, the use of “--” signifies that everything that follows it is a comment and would be ignored by the SQL interpreter.

Because of the above SQL command, the attacker can successfully authenticate and gain access to the system behind the login screen. This example highlights one very important thing: the web server passed unvalidated information directly to the database server. Unvalidated data should never be passed directly from a web server to a database server.

A buffer overflow happens when information sent to a storage buffer exceeds the capacity of the buffer. At a high level, applications accept input, process it, and provide output. When designing applications, buffers—temporary memory storage areas—are included to handle the input, processing, and output functionality. Buffer sizes are often determined ahead of time and don’t dynamically change. If an application somehow sends more information than a buffer can handle, it results in an overflow condition.

The fact that buffers can’t dynamically change size can be exploited. An attacker could create a situation where overflow data that contains executable code is placed into a storage area where the code is then executed. The first image shows two buffers, with one allocated to program A and another allocated to program B. The attacker then exploits a buffer overflow vulnerability and the data for program A overflows into the buffer for program B, as shown in the second image. If this overflow data contains malicious code, it could be executed in program B.

Two Buffers Storing Programs and Instructions

An Attacker's Data Overflows into Buffer B

Two common resources for secure coding are the OWASP Application Security Verification Standard (ASVS) and the Software Assurance Forum for Excellence in Code (SAFECode).

The Open Worldwide Application Security Project (OWASP) publishes the Application Security Verification Standard (ASVS). It aims to help organizations build and maintain secure applications, as well as help consumers and vendors align their security requirements with security offerings. It sets out three separate application security verification levels:

• ASVS Level 1 – This is completely penetration testable by humans, and it is for low assurance levels.
• ASVS Level 2 – This is the recommended level for most apps that contain sensitive data and require reasonable protections.
• ASVS Level 3 – This level is for applications that require a very high level of trust, such as those that contain medical data or that process high-value transactions.

The Software Assurance Forum for Excellence in Code (SAFECode) is a body made up of some of the biggest tech players like Microsoft and Dell. It provides a venue for tech experts and business leaders to share their insights on programs for effective software security. SAFECode’s publication, Fundamental Practices for Secure Software Development aims to help organizations begin or improve their software assurance programs.

Software configuration management (SCM) is critical for managing software changes. Good SCM helps to maintain the integrity of software, reducing the chances of bugs and other undesired behavior. Version control is a critical part of the SCM process. If errors occur in updates, it allows us to roll back to the last known functional configuration.

Another important aspect is establishing baselines, which are formally reviewed and approved specifications. When effective software configuration management practices are followed, they can minimize mistakes and security issues, as well as increase overall productivity.

Whether we run our apps on-premises or in the cloud, we need to be able to assure our stakeholders that they are built with an appropriate level of security. Software assurance and validation are critical parts of demonstrating the security of our apps.

Before we implement a security control, we want to make sure that it meets its functional requirements and we also want a mechanism to grant us assurance that it delivers on these requirements. When we want to provide assurance to our stakeholders about the overall security of our software and architectures, we use security assessment and testing.

Functional tests involve testing whether software functions as it is supposed to. These include things like basic functionality, usability, and accessibility.

Before we deploy our software into production, it must be carefully tested. Proper testing can help us determine potential security issues before they are exploited.

We should use both manual and automated testing when developing software. Manual testing means a person or a team of people are performing the tests. Automated testing means that test scripts and batch files are being automatically manipulated and executed by software. Thorough testing employs both manual and automated approaches to produce a multitude of outcomes and to achieve the best results.

Code review and access to source code can be considered from two perspectives when testing:

• Without access to the source code (also known as black-box testing).
• With access to the source code (also known as white-box testing).

Static application security testing (SAST) is conducted when an application is not running. It involves examining the underlying source code, which makes it a type of white-box testing, because the code is visible.

Dynamic application security testing (DAST) involves testing a running application and it focuses on the application and system as the underlying code executes. In contrast to static testing, dynamic testing is a form of black-box testing, because the code is not visible.

Fuzz testing is a form of dynamic testing that is premised on chaos. Fuzz testing involves throwing randomness at an application to see how it responds and what might cause it to break.

There are two major types of fuzz testing:

Below are the key differences between static application security testing, dynamic application security testing and fuzz testing.

Another type of testing known as interactive application security testing (IAST) combines elements of both SAST and DAST. Testing is performed as the application is running (DAST) with access to the code (SAST).

Software composition analysis (SCA) uses automation to find open-source software within code. The aim is to gain insight into the quality of the code, evaluate its security and check that any relevant licenses are being complied with. Open-source software and licensing can be incredibly complex, and it’s easy to overlook critical issues.

When a system is running, it’s possible to test it as if a user was using it. The system can be tested a few different ways, such as by positive testing or negative testing, which are explained in the table below. Another type of testing is abuse (also known as misuse) case testing, which we cover further down the page under Abuse case testing.

Vulnerability assessments and penetration testing (better known as pen testing) are important topics when discussing vulnerabilities and threats. As a quick review, a vulnerability can be defined as a weakness that exists in a system, while a vulnerability assessment is an attempt to identify vulnerabilities in a system.

Before you can begin a vulnerability assessment or a pen test, you need to know which assets exist. Next, the threats these assets face must be identified.

The image above shows how vulnerability assessments and penetration testing compare. Vulnerability assessments are examinations that look for security weaknesses and evaluate security controls. Vulnerability assessments can be automated and are relatively fast. A report documenting the findings and recommendations is compiled at the end of a vulnerability assessment.

Penetration tests are similar to vulnerability assessments, but they tend to involve more manual work. They involve finding vulnerabilities and then trying to exploit them to prove they are exploitable. The steps of a penetration test are: