CCSP Domain 3 - Attack Vectors & Risks
Download a FREE Printable PDF of all the CCSP MindMaps!
Your information will remain 100% private. Unsubscribe with 1 click.
Transcript
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 attack vectors and risks in Domain 3, to understand how they interrelate, and to guide your studies.
This is the fourth of seven videos for Domain 3. I have included links to the other MindMap videos in the description below. These MindMaps are a small part of our complete CCSP MasterClass.
Attack Vectors
There are a wide variety of attack vectors that you need to be aware of if you want to keep your cloud environments secure.
Common
A bunch of these attack vectors are not unique to the cloud. These are attack vectors that we have in existing data centers, and the cloud. So most of these are not going to be anything new to you.
Denial of Service
Denial of service attacks prevent users from being able to access services. A common example is a DDoS attack–a distributed denial of service attack–which involves a malicious flood of traffic overwhelming a service, preventing legitimate users from accessing the service.
Malware
Malware is malicious software that’s designed to harm, exploit, or allow unauthorized access to a computer system or network. Things like viruses, worms, trojans, ransomware, logic bombs, etc.
System vulnerabilities
Some system vulnerabilities are the same in the cloud as they are under traditional environments. If you run Windows on a cloud-based VM, the OS itself has the same vulnerabilities as running Windows on your own hardware
XSS, CSRF, SQL Injection, etc.
Cloud services are susceptible to common web application vulnerabilities like XSS, CSRF, SQL injection and buffer overflows. We need to design our cloud services carefully, using techniques like input validation, to mitigate the risks stemming from these issues.
Malicious insiders
Malicious insiders are employees, contractors, or other internal individuals that cause harm to the organization and its systems. They pose a substantial threat, because they can already have access to sensitive data and systems–they may have access to certain critical systems and know where sensitive data is stored–or how to cause particular harm to the organization.
Social engineering
Social engineering involves manipulating people into doing things that they shouldn’t. Phishing emails that trick people into handing over their passwords or financial details are a common example. Another emerging threat is AI voice cloning, which an attacker can leverage in attacks such as impersonating your boss to trick you into making a fraudulent funds transfer.
Advanced Persistent Threats
Advanced persistent threats–APTs–are highly skilled and well-funded attackers that infiltrate networks. They generally take a low and slow approach, penetrating the network quietly and trying to stay undetected for a long period of time. Bit by bit, they try to expand their access and escalate their privileges to steal sensitive data or cause other problems–without being detected. APTs are particularly difficult to detect and can cause major havoc.
Specific to Cloud
Now, let's dive into a bunch of attack vectors that are specific to the cloud–you should obviously pay particular attention here.
Insufficient Due Diligence
Organizations are responsible for approaching any cloud venture with due diligence. They need to understand the risks and opportunities, and take sufficient measures to limit the downsides. Put simply, if a customer jumps headfirst into the cloud without sufficiently thinking through things like interoperability, portability, reversibility, and minimizing vendor lock-in, then that customer is going to have a bad time. It’s crucial to think through the decision to move to the cloud carefully, and pick a provider that best meets the organization's needs–to do your due diligence.
Guest Escape / VM Hopping
Guest escape is a virtual machine security breach where an attacker breaks out from a VM to access the hypervisor or other VMs on the same host.
VM hopping, also called VM jumping, is a security exploit in which an attacker accesses one virtual machine in order to attack another VM hosted on the same physical machine.
Hyperjacking
Hyperjacking involves an attacker taking control of an existing hypervisor. This type of attack has absolutely occurred in the wild.
Hyperstack attack
Hyperstack attacks on the other hand are much more rare as they would be incredibly difficult to pull off, but they could put an organization at great risk. A hyperstack attack involves an attacker removing an existing hypervisor and replacing it with a malicious hypervisor, giving them access to everything running through the hypervisor.
Insecure Interfaces / APIs
APIs are used extensively in the cloud. APIs are the prominent way that everything in the cloud is controlled. So, if we have insufficient access control or encryption that leads to unauthorized access to and usage of APIs, this can lead to serious security issues.
Provider’s infrastructure
It’s incredibly important for cloud providers to secure their underlying infrastructure. You should only use a provider that can demonstrate appropriate security, which is often done through a third-party audit. If your cloud provider's infrastructure is not secure, there is no way you can securely run your virtualized systems on top of it.
Shared technology
In public clouds, customers are sharing the same underlying physical hardware. While this is a core aspect of how the cloud can bring down costs, it also means that if an attacker finds a vulnerability in the services one customer is using, then that vulnerability could also exist in many of the other customers sharing the service.
Account hijacking
Account hijacking is a major risk in cloud environments, particularly for privileged accounts that have access to the management plane. The management plane controls so much of the overall service, which means that a compromise at this level is essentially game over in terms of security.
Risks
Alright, let's now move on to a whole list of risks that are common and specific to the cloud.
Common
Starting with the common risks:
Data Loss / Breach
Data Loss involves data becoming corrupted, deleted, or made unreadable.
A data breach is when information is stolen or taken from a system without the knowledge or authorization of the system's owner.
Data Integrity
Integrity is a critical property that we want for our important data. It essentially means that it hasn’t been tampered with or manipulated.
Compliance & regulatory
Compliance is an important, yet challenging aspect of working in the cloud. The flexible and international nature of cloud services makes it easy to store or process data in other countries, but this could put your organization at risk. We must abide by the regulations of the countries that our organizations operate in, and sometimes there may be restrictions about where you can collect and store data.
Specific to Cloud
The following risks I’m now going to discuss are specific to the cloud.
VM Sprawl
VM Sprawl. In the cloud, it's incredibly easy to spin up new VMs or other infrastructure. This ease can lead to you deploying too many and forgetting about them. If you forget about some VMs that you’ve deployed, you can neglect to patch them and maintain appropriate security, which could lead to insecure systems and a way for the baddies to break into your infrastructure.
Sensitive data within a VM
When a VM is running, it often has a bunch of security controls protecting it, such as a host-based IDS, antimalware and DLP. When we suspend a VM, essentially turning all the data from a VM into a file, none of these security controls are running anymore. This puts sensitive data at risk, unless you are placing other security controls on the VM file, such as encryption.
Dormant VMs
A dormant VM won’t get patched during the normal patching cycle. This can lead to instant-on gaps.
Instant-on gaps
When you first power on a dormant VM, it may be missing patches, which means that it could have a number of vulnerabilities. An instant on gap is the period of vulnerability in between waking the VM and getting it patched. There are two major ways to deal with Instant-on gaps:
- As part of your patch management process, remember to wake up and patch all dormant VMs during a patch cycle. It’s hard to do this and not miss some VMs somewhere.
- The more common option is to use quarantine. When you wake up a dormant VM, it is immediately put in quarantine and blocked from accessing most of the internal network and especially the internet–thus vastly reducing the chance the potentially vulnerable VM is compromised before you get a chance to patch it. Once the VM is patched and brought into compliance with the latest configuration requirements it can be removed from quarantine.
Resource exhaustion
Resource exhaustion is a risk that can impact certain cloud setups. As an example, if you have a VM sharing a compute node with another VM that is getting hammered in a DDoS attack, your VM may not be able to access the resources it needs to effectively complete its tasks.
Hypervisor security
Hypervisors have full visibility into everything that the VMs on top of them are doing. This makes hypervisor security absolutely critical–if a hypervisor is compromised, so are all of your VMs.
Data comingling
Data comingling. Public clouds involve customers sharing the same underlying physical hardware. Although cloud providers should have logical isolation in place, there is a chance for this to fail, and for customers to be able to access the data of one another. This is one reason why you shouldn’t store highly sensitive data on a public cloud.
Inter-VM communication (blindspots)
Inter-VM communication and blindspots are also important to think about. One example of a blindspot is when you have two VMs communicating with each other on the same hypervisor. If your IDS is attached to a switch out on the software-defined network, the VMs won’t bother routing the traffic out to your IDS, instead, they will just communicate directly through the hypervisor, meaning that your IDS won’t be able to see the traffic. So, the risk here is you will inevitably have these sorts of blindspots in the cloud and you need to identify them and figure out how to mitigate the risk.
That’s all for our review of attack vectors and risks within Domain 3, covering the central 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!
