Now that we understand security posture, defense in depth, and shared responsibility, as you begin to architect cybersecurity for the cloud, we will discuss the makeup of a security operations team and the levels of a cybersecurity attack so that you gain an understanding of how cybersecurity architecture can help protect against these threats. You will see that a successful cybersecurity architecture is about more than just infrastructure and tooling; it is as much about people and processes as it is about technology.
Security Operations
In discussing security operations, you will hear terms such as red team, blue team, yellow team, purple team, white hat, and black hat. Let us define each of these:
- Red team: This is a team within the cybersecurity operation of the company that will conduct simulated attacks and penetration testing on the company infrastructure.
- Blue team: This team focuses on the defenses and the response to attacks. These are the incident responders within cybersecurity operations.
- Yellow team: These are developers and third-party developers that the blue team should be working with on defenses within the development of controls.
- Purple team: This team focuses on the methodology around the security architecture and protection. The purple team works closely with the red and blue teams to maximize the cybersecurity capabilities of the company. The purple team relies on the continuous feedback and lessons learned from the red and blue teams to improve the effectiveness of controls that are in place for vulnerability assessment, threat hunting and detection, and network monitoring.
- White hat: These are considered ethical hackers. Ethical hackers use the tools of a bad or malicious hacker to attack a company’s systems but with their permission.
- Black hat: These are malicious hackers who are attempting to gain some level of control and do harm to the company that they are attacking.
Now that you understand the roles and responsibilities within the Security Operations department, the next section will discuss the scope of cybersecurity in a cloud infrastructure.
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 protect and secure their environment on the cloud. Let us discuss each of the 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
Although it may not seem directly relevant to a topic on cloud computing, most organizations that are not start-up businesses will commence their cloud journey with an on-premises infrastructure. They are likely to have a hybrid cloud infrastructure for many years after starting a cloud migration project, before finally having a fully cloud-native architecture (though for some businesses, it may not be practical or possible from an operational and/or regulatory perspective to be fully cloud-native).
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’s responsibility for maintaining the operating system. The cloud provider handles all security patches and updates. Platform services have baseline security controls for the network, applications, and identity infrastructure. These are in place to protect against threats that could affect multiple customers who 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 it is the customer’s responsibility to turn them 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 use it immediately. This simplifies 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 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, 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.1 that, although there may no longer be an on-premises infrastructure, 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 users.
Many companies continue to have this private infrastructure while also utilizing public cloud services. These hybrid infrastructures vary across all 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 are 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.
In Chapter 2, Build an Overall Security Strategy and Architecture, you will explore 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 is straightforward and simple, but if you were to constantly ask users to enter their usernames and passwords, 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.4:
Figure 1.4: A flowchart where an initial signal leads to an informed decision based on organizational policy, which is then enforced across resources
Note
While not covered in detail in the exam, other important research to review on zero trust is the Cybersecurity and Infrastructure Security Agency (also known as CISA) Zero Trust Maturity Model (ZTMM), recently updated to version 2.0. For more information on the CIA ZTMM, go to this link: https://www.cisa.gov/zero-trust-maturity-model.
As we discussed in the Building a Defense-in-Depth Security Posture section earlier in the chapter, in 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 a 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. As demonstrated, there are several layers within your infrastructure where you could defend against attack, but also opportunities for attackers to gain access to your systems and data.
In the later Defense in Depth: A Real-Life Example section, we will demonstrate how this all comes together by looking at a real-world example of an attack.
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, whether on-premises, hybrid cloud, or cloud-native.
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 framework for hunting for and identifying threats.
Note
For more information, please use the following link: https://attack.mitre.org/matrices/enterprise/cloud/.
This framework is extensive and covers the many diverse types of tactics, techniques, and procedures (TTPs) that can be used by attackers in combination, across several layers of the infrastructure, something that is often referred to as an attack path.
While the MITRE ATT&CK framework could fill a book, we can cover in this book some of the types of threats that are common, and later demonstrate how they can be chained together to form an attack path.
The Cloud Security Alliance (CSA) also provides guidance about common attacks and threats to cloud environments.
Note
More information can be found at this link: https://cloudsecurityalliance.org/artifacts/security-guidance-v5.
Finally, it is important to be aware of and understand the Open Web Application Security Project (OWASP) Top 10 Application Security Threats.
OWASP is a nonprofit organization dedicated to improving the security of software. It provides free and open-source tools, documentation, and training for web application security.
One of OWASP’s most well-known projects is the OWASP Top Ten, a standard awareness document for developers on web application security. It highlights the most critical security risks to web applications and offers guidance on how to mitigate them.
The current Top 10 at the time of writing is as follows:
- Broken access control: Improperly enforced restrictions on authenticated users, allowing them to access unauthorized functions or data.
- Cryptographic failures: Issues related to the protection of data in transit and at rest, often due to weak or improperly implemented cryptographic algorithms.
- Injection: Flaws such as SQL, NoSQL, and LDAP injection, where untrusted data is sent to an interpreter as part of a command or query.
- Insecure design: Security weaknesses due to design flaws, rather than implementation issues.
- Security misconfiguration: Incorrectly configured security settings or default configurations that are insecure.
- Vulnerable and outdated components: Using components with known vulnerabilities or outdated software.
- Identification and authentication failures: Issues with authentication mechanisms, such as weak passwords or flawed session management.
- Software and data integrity failures: Problems with software updates, critical data, and CI/CD pipelines that can lead to unauthorized access or data corruption.
- Security logging and monitoring failures: Inadequate logging and monitoring, which can delay the detection of breaches.
- Server-side request forgery (SSRF): When a web application fetches a remote resource without validating the user-supplied URL, leading to the potential exposure of internal systems.
These categories help organizations prioritize their security efforts and address the most pressing vulnerabilities.
Note
You can read more about OWASP at https://www.owasp.org.
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 subject to external attacks. We will discuss this more as we discuss some of these internal threats in this section.
Shadow IT
Shadow IT is extremely common within companies. This is caused when people in the organization use applications 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.5:
Figure 1.5: Shadow IT prevention life cycle
Figure 1.5 shows that Phase 1 is Discover and identify, that is, identifying shadow IT (IT not managed by the IT department) and assessing the risk of those apps.
It then moves into Phase 2, where we evaluate whether the applications identified are compliant with relevant company and regulatory standards and risk appetite, before analyzing the usage of those applications.
Finally, we move into Phase 3: Manage and monitor. In this phase, we manage those discovered shadow applications, apply appropriate security controls, and then monitor them.
The entire process is depicted as a life cycle, as the security posture must be continuously assessed to ensure a secure environment.
Patch Vulnerabilities
Patch vulnerabilities are another internal threat to a company. These vulnerabilities can be created by users who defer patch installation and the restarting 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 potential exploitation. 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 with these privileges is an internal and 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 allow 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 required to access it.
Developer Backdoors
When developing applications, access to the application infrastructure may be provided through an open port or service path. 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. Like 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 was 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. Companies must protect their sensitive data from being exposed to those 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 against 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 because they are created by 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 us 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 – Network and Application Layer
Denial-of-service attacks are a 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. For example, remote internal users may not be able to access the resources required 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.6 shows how these attacks threaten the ability of an actual user to access a system:
Figure 1.6: Illustration of a denial-of-service attack
The longer that a company is subject to these types of attacks, the greater the cost in lost revenue and time. Therefore, it is important that a company monitors these attacks and can block their source quickly to minimize the impact.
Brute-Force Attacks – Network and Application Layer
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 by finding an opening within those systems and then, as the name suggests, using brute force to access them. These attacks are carried out by 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.7 shows how an attacker utilizes multiple systems and attempts to gain access to systems:
Figure 1.7: An attacker scanning public IP addresses for open ports, then attempting to gain access using common usernames once an open port is found
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.
Software Vulnerabilities – Application, Network, Endpoint, Identity, and Access Management Layers
Software vulnerabilities allow external threats where attackers take 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 in 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 can 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 preventing these exploits from becoming attacks.
Figure 1.8 illustrates the life cycle of a zero-day threat, detailing the stages from the creation and discovery of a vulnerability, through the availability of an exploit, the period of risk before and after public disclosure, and finally, the release and installation of a patch by the vendor.
Figure 1.8: The vulnerability management life cycle
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 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.9 shows an attacker that has gained access to an authorized user’s identity to gain access to another user:
Figure 1.9: Attacker-in-the-middle (AiTM) attack: Attacker intercepts and impersonates users in a communication
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.
Injection Attacks – Application and Data Layers
Injection attacks are a threat primarily to databases that are connected to our applications. These threats are like 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.10 illustrates the process of how this attack may take place on a SQL database:
Figure 1.10: SQL injection attack: Hacker injects malicious SQL to access and manipulate database records
This injection attack is caused by poor authentication and monitoring controls for the database. Figure 1.11 shows the process of how the attacker gains access to the user’s session cookies:
Figure 1.11: Cross-site scripting (XSS) attack: An attacker injects a malicious script into a vulnerable website to steal visitors’ session cookies
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.
Note
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 10 Web Application Security Risks: https://owasp.org/Top10/.
Figure 1.12: Security risk matrix visualized
In Figure 1.12, the x axis shows the impact scale, indicating the severity of the risk. The y axis shows the likelihood scale, representing the probability of the risk occurring. The intersection of these scores generates a risk score, guiding the prioritization of remediation efforts.
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.
Social Engineering
Social engineering attacks manipulate human behavior to gain unauthorized access to systems or information. Here are some common types and techniques:
- Phishing: Attackers send fraudulent emails or messages that appear to come from legitimate sources, tricking recipients into revealing sensitive information or clicking on malicious links.
- Spear phishing: A more targeted form of phishing, where attackers customize their messages to a specific individual or organization, often using personal information to appear more convincing.
- Whaling: Like spear phishing but targets high-profile individuals such as executives, aiming to gain access to sensitive corporate information.
- Baiting: Attackers offer something enticing, such as free software or a gift, to lure victims into providing personal information or downloading malware.
- Pretexting: Attackers create a fabricated scenario to trick victims into divulging information or performing actions that compromise security.
- Quid pro quo: Attackers promise a service or benefit in exchange for information or access, such as pretending to be IT support and offering help in return for login credentials.
- Tailgating/piggybacking: Attackers physically follow authorized personnel into restricted areas without proper authentication.
- Vishing: Voice phishing, where attackers use phone calls to trick victims into revealing personal information.
- Smishing: SMS phishing, where attackers send fraudulent text messages to deceive victims into providing sensitive information.
- Honeytrap: Attackers use romantic or seductive approaches to manipulate victims into sharing confidential information.
Understanding these techniques helps in developing effective security awareness programs and implementing measures to protect against social engineering attacks.
United States
Great Britain
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
Singapore
Hungary
Ukraine
Luxembourg
Estonia
Lithuania
South Korea
Turkey
Switzerland
Colombia
Taiwan
Chile
Norway
Ecuador
Indonesia
New Zealand
Cyprus
Denmark
Finland
Poland
Malta
Czechia
Austria
Sweden
Italy
Egypt
Belgium
Portugal
Slovenia
Ireland
Romania
Greece
Argentina
Netherlands
Bulgaria
Latvia
South Africa
Malaysia
Japan
Slovakia
Philippines
Mexico
Thailand
