Understanding the scope of cybersecurity in the cloud
A key to building a cybersecurity architecture is to know your responsibility as a cybersecurity architect and the responsibility of the cloud provider, depending on the type of services that you are utilizing.
In the following sections, you will learn how security controls will be utilized and put into place by the cybersecurity architect based on the shared responsibilities between the cybersecurity architect and providers.
Shared responsibility scope
It is important for a customer or company to understand their relationship to properly protecting and securing their environment on the cloud. Let us discuss each of these services and the level of security responsibility. As a cybersecurity architect, you should think about how a control pertains to the shared responsibility model and to a defense-in-depth security approach.
On-premises responsibility
On-premises infrastructure would be synonymous with a private data center. This is the equipment and infrastructure that the company owns. Therefore, the responsibility for security controls across all the levels of defense in depth is the company’s responsibility. We have yet to consume any cloud services, so there is no responsibility for the cloud provider.
IaaS shared responsibility
Infrastructure-as-a-service, or IaaS, is the service that is most like a private data center. The primary difference between IaaS infrastructure and an on-premises data center is that the cloud provider is responsible for the physical security of the data center, any physical network equipment, and the hosts that provide our virtual servers. The customer is responsible for the following for IaaS:
- Putting all security controls in place to protect and patch the operating system
- Creating rules and infrastructure services such as firewalls to protect the network
- Managing and protecting applications from common threats
- Protecting identities and controlling access
- Patching and protecting endpoint devices
The customer is always responsible for the protection and governance of their data. This is shared across any of the cloud services in the shared responsibility model.
PaaS shared responsibility
Platform-as-a-service, or PaaS, removes the customer responsibility of maintaining the operating system. The cloud provider handles all of the security patches and updates. Platform services also generally have a level of baseline security controls in place for the network, applications, and identity infrastructure. These are in place mainly to protect against threats that could affect multiple customers that are utilizing these platform services. These baseline controls may not be seen as enough for some companies, so options to increase these controls are in place and are the customer’s responsibility to turn on. Many of these capabilities will be discussed later in this book. Within PaaS, the responsibility for access management, endpoint protection, and data protection and governance remains the sole responsibility of the customer.
SaaS shared responsibility
SaaS, or software-as-a-service, provides an application where you purchase a license on a per-user basis, log in to that application, and are able to use it immediately. This is simplifying these services to the consumer level, as there is a level of configuration that takes place for business applications. Microsoft 365 is an example of a SaaS application. The suite of software, Office 365 and SharePoint, for example, is available to use when you assign a license to a user. The cloud provider, in this case, Microsoft, has all of the security controls in place for protecting the application, network, operating system, and physical environment.
Protection within SaaS is focused on identity and access management for the customer. Therefore, proper configuration of the identity and access controls is extremely important and ties into additional controls within endpoint protection and data protection and governance. In a cloud infrastructure, SaaS, PaaS, and IaaS are all at play and need to be focused on within the cybersecurity architecture.
Note in Table 1.2 that there is a shared responsibility for the identity infrastructure. Microsoft does provide a level of security controls to protect user identities as a baseline, but the customer is responsible for increasing that level of protection. An example here would be turning on multi-factor authentication; it is provided by Microsoft, but the customer needs to enable the service for some or all of their users.
|
Responsibility |
IaaS |
PaaS |
SaaS |
|
Data governance and rights management |
Customer |
Customer |
Customer |
|
Client endpoints |
Customer |
Customer |
Customer |
|
Account and access management |
Customer |
Customer |
Customer |
|
Identity and directory infrastructure |
Customer |
Microsoft/ Customer |
Microsoft/ Customer |
|
Application |
Customer |
Microsoft/ Customer |
Microsoft |
|
Network controls |
Customer |
Microsoft/ Customer |
Microsoft |
|
Operating system |
Customer |
Microsoft |
Microsoft |
|
Physical hosts |
Microsoft |
Microsoft |
Microsoft |
|
Physical network |
Microsoft |
Microsoft |
Microsoft |
|
Physical data center |
Microsoft |
Microsoft |
Microsoft |
Table 1.2 – Shared responsibility for SaaS, PaaS, and IaaS
Many companies continue to have this private infrastructure while also utilizing public cloud services. These hybrid infrastructures would vary across all of the areas of responsibility to account for their overall security posture. As we continue through this book, the services that are discussed fall into one of the three main categories of IaaS, PaaS, or SaaS, but may also have a hybrid component to support on-premises infrastructure.
You now should have a strong understanding of defense-in-depth security and shared responsibility in the cloud. As you should have noticed, account and access management is an area of customer responsibility no matter what service is being consumed.
Principles of the zero-trust methodology
In the previous section, we identified that the responsibility for securing the physical infrastructure for cloud services lies with the cloud provider, Microsoft. Since Microsoft is responsible for the first layer of defense in our defense-in-depth security posture, the first layer that we are responsible for as a company is the identity and access layer. Therefore, the statements “identity is the new perimeter” and “identity is the new control plane” have become extremely important in securing a cloud infrastructure. In Chapter 2, Building an Overall Security Strategy and Architecture, we will discuss the role of identity and access management within a cloud and hybrid infrastructure, and the services that Microsoft provides for protecting resources at this layer. It is important to understand the core concept that a company should adhere to when securing identity and access. This concept is the zero-trust methodology.
The zero-trust methodology is a process of continuously requiring someone on the network to verify that they are who they say that they are. The concept seems to be straightforward and simple, but if you were to constantly ask users to enter their username and password, they would get frustrated. To avoid this frustration, a zero-trust implementation utilizes various signals that alert about potentially anomalous behavior, leaked credentials, or insecure devices that trigger the need for a user to reverify their identity. These signals lead to a decision on what is needed to provide access to applications, files, or websites. This architectural pattern of zero-trust identity is shown in Figure 1.3:
Figure 1.3 – Diagram of the zero-trust model architecture
As we discussed in the defense-in-depth section earlier in the chapter on the defense-in-depth strategy, the physical controls are provided by Microsoft or the cloud provider; therefore, identity and access become the first layer of defense for a company and cybersecurity architect to protect. The zero-trust model goes much further than simply identity and access, with networks, devices, applications, infrastructure, and data within the model and the defense-in-depth strategy.
A cybersecurity architect needs to know what the company can expect when it comes to vulnerabilities and attacks. The following sections will define some common internal and external threats and attacks.
Common threats and attacks
As cybersecurity architects, it is our responsibility to identify and design controls that address and protect against threats within our company infrastructure.
Threats can be internal or external. They also are not always malicious or meant to cause harm to the organization. We will discuss this in more detail as we identify some of these threats in the next sections. The threats listed are examples of internal and external threats and are not expected to be an exhaustive list.
When architecting a security operations infrastructure, many solutions utilize the MITRE ATT&CK for hunting and identifying threats. For more information, please use the following link: https://attack.mitre.org/matrices/enterprise/cloud/.
The Cloud Security Alliance (CSA) also provides guidance about common attacks and threats to cloud environments. More information can be found at this link:
Let’s start by discussing internal threats.
Internal threats
Internal threats are caused when a vulnerability is exposed by an internal user or resource. As stated previously, these are not always malicious or meant to cause harm; they can be accidental and created due to a lack of education and awareness. These internal threats, in some cases, can become vulnerabilities that become subject to external attacks as well. We will discuss this more as we discuss some of these internal threats in this section.
Here are some common internal threats.
Shadow IT
Shadow IT is extremely common within companies. This is caused when people within the organization utilize applications that are not tested and approved by the company. Not all shadow IT causes a threat to the company, but not properly monitoring these applications can create vulnerabilities within the company. One way to discourage shadow IT is to have company policies in place regarding the use of third-party applications that are not approved on devices that access company resources. In addition, utilizing mobile device management or mobile application management can also deter the use of these applications by blocking access to them with device policies and conditional access. Educating users is another valuable aspect of stopping shadow IT from becoming prevalent within the company.
The life cycle of monitoring and preventing shadow IT within your company is shown in Figure 1.4:
Figure 1.4 – Shadow IT prevention life cycle
Next, we will discuss patch vulnerabilities as an internal risk.
Patch vulnerabilities
Patch vulnerabilities are another internal threat to a company. These vulnerabilities can be created by users that defer patch installation and restart of their devices due to inconvenience. The most frequent patches that are provided for device operating systems are security patches. Therefore, if these patches are not installed company-wide in a timely manner, the entire company is vulnerable to a potential exploit. As was the case with shadow IT, a way to discourage deferring patch installation is through educating users on the risks that avoiding these updates poses to the company and their own devices. Automating patch updates and turning off the ability to defer them through mobile device management is also an option for companies to mitigate this threat.
Elevated privileges
Elevated privileges are created when users have administrative rights to resources within the information technology environment that may not be required for them to complete the job tasks. A user that has these privileges is actually both an internal and an external threat. As an external threat, if a user’s credentials are compromised, then an attacker could gain access to sensitive information. As an internal threat, someone who has elevated privileges that allows them to access information that they are not required to view for their job could represent a privacy concern for the company.Therefore, it is important to review and audit user access and do our proper due diligence so that sensitive information is only available to those that are required to access it.
Developer backdoors
When developing applications, access to the application infrastructure may be provided through an open port or service path that is open to the public. While the application is in development and isolated from the production infrastructure and data, this access helps developers gain access, work on, and test the application. However, if these developer backdoors are left in place after production, this could allow access to sensitive data and even access to application code that could be altered. Similar to privileged access, this could be thought of as an internal and an external threat. The exposure of these backdoors becomes a vulnerability that can be leveraged by attackers. It is an internal threat since it is created through the internal application development process.
Data exposure
Data exposure is another threat here that could fall into both the internal and external threat categories. It is imperative that companies protect their sensitive data from being exposed to those that are not authorized to access it. Not having proper controls in place to protect sensitive data through access, authentication, and authorization could lead to exposure from either internal or external sources. Therefore, masking data from unauthorized users can protect from this exposure of data. Avoiding open and anonymous access to storage accounts will also protect against data exposure.
Perimeter threats
The final internal threat that we will discuss in this section is perimeter threats. These threats are considered internal due to the fact that they are created by having inadequate controls in place to protect the internal infrastructure. Perimeter threats could be caused by allowing users to access resources through insecure open ports or transferring data through unencrypted transmission channels. IT professionals should have proper controls in place to avoid these threats and to monitor who is accessing data from inside and outside the company firewall.
As stated in the previous sections, internal threats can also become external vulnerabilities if not properly addressed with controls. It is an IT professional’s responsibility to use proper due care and due diligence to protect the company.
Now that we have discussed some potential internal threats, let’s review some potential external threats.
External threats
The previous section focused on threats that are created internally by users, developers, or IT staff that could cause data exposure to unauthorized personnel or allow external attackers into the company infrastructure. In this section, we will discuss external threats that are initiated by external sources. These external threats can cause disruption to the company and customers, causing decreases in efficiency and revenue.
Denial-of-service attacks
Denial-of-service attacks are a very common external threat to companies. Also referred to as distributed denial-of-service, or DDoS, these attacks flood your ISP with thousands of requests to overwhelm the ISP and the company infrastructure to the point that actual users attempting to access resources cannot get through and their requests time out. A DDoS attack is not a threat that is based on theft, and no personal or company data is at risk during these types of attacks. These attacks are damaging to a company from a revenue and efficiency standpoint. Remote internal users may not be able to access resources that they require to perform their job-related tasks. In addition, customers may not be able to access the company website to browse and order, costing the company revenue.
Figure 1.5 shows how these attacks threaten the ability of an actual user to access a system:
Figure 1.5 – A denial-of-service attack
The longer that a company is under these types of attacks, the more that it will cost them in lost revenue and time. Therefore, it is important that a company monitors these attacks and is able to block the source of them quickly to minimize the impact.
Next, we will look at brute-force attacks.
Brute-force attacks
In contrast to a DDoS attack, where there is no threat of personal or company data being stolen, this is not the case with a brute-force attack. A brute-force attack is a threat with the primary purpose of gaining access to a company’s systems to digitally burglarize data. Brute-force attack threats are commonly tied to some of the internal threats mentioned previously in this chapter. These types of threats attempt to gain access to the company systems through finding an opening within those systems and then, as the name suggests, using brute force to access them. These attacks are carried out through scanning for ports that are open to the internet, finding systems that have public internet addresses on those ports, and then using commonly used usernames and passwords on systems to gain access.
Figure 1.6 shows how an attacker utilizes multiple systems and attempts to gain access to systems:
Figure 1.6 – A brute-force attack
When a brute-force attack is successful, the company is exposed to potential theft of sensitive personal or company data that may be on that system, or other databases and file shares that are accessible from that system.
Now, let’s look at threats from vulnerability exploits.
Software vulnerabilities
Software vulnerabilities allow external threats where attackers are taking advantage of some of the controls that are not in place to protect the company. Some of these vulnerabilities can be caused by the internal threats that were mentioned within the previous section, such as development backdoors and patch vulnerabilities. Improperly securing application APIs also creates a vulnerability that an attacker can exploit. The threat of a software vulnerability may lead to data breaches where an attacker is able to gain unauthorized access to sensitive information and applications.
Many vulnerability exploits are caused by operating system code, third-party libraries, or application code that an attacker has found could be exploited. These are called zero-day exploits and are the most common of widespread threats to systems. Keep in mind that this is an external attack but is initiated through an internal user accessing a malicious email or link. Proper user education regarding the origination of emails and links can assist in avoiding these exploits from becoming attacks.
Figure 1.7 shows the life cycle of the zero-day threat from an attack through patching of the system:
Figure 1.7 – Vulnerability exploit life cycle
Next, we will look at IP and identity spoofing.
IP or identity spoofing
An IP or identity spoofing threat comes from an attacker pretending to be someone within the company or utilizing an IP address that is seen by systems as internal. Attackers that leverage these threats have most likely gathered information on the company through some type of phishing campaign that has allowed them to identify usernames, passwords, and IP addresses that have access to systems. These attacks are used to gain access to systems. Social engineering and phishing attacks are methods that can be used to gain this level of access.
Figure 1.8 shows an attacker that has gained access to an authorized user’s identity to gain access to another user:
Figure 1.8 – Identity spoofing
Proper user education on phishing email campaigns and having a zero-trust model for user authentication and access will help to protect against these types of attacks.
Let’s next discuss injection attacks as an external threat.
Injection attacks
Injection attacks are a threat primarily to databases that are connected to our applications. These threats are similar to brute-force attacks, as they make an active effort to gain access to systems. The way that injection attacks gain access is by sending a command or query to a database that takes advantage of a known flaw in the database. This command code or query is then executed without proper authorization, allowing the attacker to gain access to sensitive data.
Figure 1.9 illustrates the process of how this attack may take place on a SQL database:
Figure 1.9 – A SQL injection attack
The process of this injection attack is caused mainly by poor authentication and monitoring controls in place for the database.
Next, we will discuss cross-site scripting.
Cross-site scripting
Similar to injection attacks that take advantage of security flaws within databases, cross-site scripting threats take advantage of insecure code and validation within a website. Attackers will use the lack of security to create a redirection from the secure website to an insecure website created by the attacker. These attacks are used primarily to gain access to the device that is accessing the website and execute malicious scripts and malware that could gain access to sensitive personal information on the device.
Figure 1.10 shows the process of how the attacker gains access to the user’s session cookies:
Figure 1.10 – A cross-site scripting attack
The visitor to the website has no knowledge that their session cookie has been intercepted and that they have been redirected. This allows the attacker to interact with the user’s device and activate malicious code and malware.
Other web-application-based attacks
The external threats to companies and users are always evolving. A great resource to keep up with the most current risks is the OWASP Top Ten Web Application Security Risks: https://owasp.org/www-project-top-ten/.
Figure 1.11 – Security risk
Throughout this book, we will discuss the ways that a cybersecurity architect can evaluate and design infrastructures to protect and remediate potential internal and external threats and vulnerabilities before they are exploited and turn into attacks.
