This chapter will provide an overview of what cybersecurity is and why it is important. This chapter will also discuss the evolution of cybersecurity and cyber attacks as cloud technologies have become more prevalent. Once you have completed this chapter, you will have an understanding of what is meant by cybersecurity and how it has changed as we have moved our workloads from on-premises data centers to the cloud.

In this chapter, we are going to cover the following main topics:

• What is cybersecurity?
• The evolution of cybersecurity from on-premises to the cloud
• Cybersecurity architecture use cases
• Understanding the scope of cybersecurity in the cloud

To be able to understand the role of the cybersecurity architect, you should first understand what is meant by the term cybersecurity. The term is used in many different contexts within security, compliance, and identity. To set a base level of understanding for this book, we will use the definitions provided by NIST, the National Institute of Standards and Technology.

According to NIST, there are multiple definitions for the term cybersecurity; the first part of the NIST definition is “the prevention of damage to, protection of, and restoration of computers, electronic communications systems, electronic communications services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentications, confidentiality, and nonrepudiation.”

The next part of the NIST definition is “the process of protecting information by preventing, detecting, and responding to attacks.”

They also define cybersecurity for the protection of federal agencies as the ability to protect or defend the use of cyberspace from cyber attacks.

Finally, cybersecurity is also defined as “the prevention of damage to, unauthorized use of, exploitation of, and – if needed – the restoration of electronic information and communications systems and the information they contain, in order to strengthen the confidentiality, integrity, and availability of these systems.”

These are just four areas and approaches that can be taken when it comes to cybersecurity. Overall, the underlying factors here are that you must take the steps to provide assurance for maintaining the confidentiality, integrity, and availability of your data and systems. A cybersecurity architect taking the proper due care and due diligence in analyzing and assessing risks and controls that are in place is an example. Relevant systems consist of the infrastructure, applications, databases and storage, and solutions that your company is using for processing and delivering information to users.

Further information can be found at this link: https://csrc.nist.gov/glossary/term/cybersecurity

At this link, you will find the definition of cybersecurity and the various approaches that can be taken toward it. In the next section, you will learn more about how the role of cybersecurity has changed from an on-premises to a cloud network and infrastructure.

When protecting an on-premises data center and infrastructure, a cybersecurity architect designs many of the controls to protect physical assets and keep bad actors from entering at either physical data center entry points or internet service provider (ISP) network entry points. Traditionally, these protections would have been a combination of physical security appliances, such as firewalls for packet investigation, and protection against attacks through endpoint devices by only allowing access to the data center with SSL VPN-encrypted connections. These devices were managed by the company and given antivirus and anti-malware software to mitigate potential attacks.

As companies move to more cloud-native applications, such as Microsoft 365, and build infrastructure on cloud providers, such as Microsoft Azure, companies have moved their responsibility for security away from physical to virtual environments. This creates new vulnerabilities that the company must identify and plan ways in which to mitigate against threats. The following sections will discuss how a cybersecurity architect should begin to plan for protection and controls within a cloud and hybrid infrastructure.

Defense-in-depth security strategy

When protecting the cloud and hybrid infrastructure, there are many aspects that need to be considered. As you go through the various solutions offered within Microsoft 365 and Azure, these methodologies and principles play a key role in the process of protecting resources, identity, and data. One of the primary strategies for protecting your company is through defense in depth. Having a strong defense-in-depth security posture addresses the areas of the cybersecurity kill chain. The next section will discuss the concept of building a defense-in-depth security posture.

Building a defense-in-depth security posture

In order to protect your company from cyber attacks, you should have controls in place that address the stages of cyber attacks and that maintain a defense-in-depth security posture. When planning for the security of information technology resources, protecting one aspect is not enough; every aspect of the infrastructure should have security controls in place to protect at all levels. Controls are the services or solutions that we have in place to properly secure and protect the resources at that level of defense.

Each of these levels of defense is important since attackers look for various entry points into a company network. The levels of defense in depth are shown in Figure 1.1.

Figure 1.1 – Defense-in-depth security

Now that you know why defense in depth is important, let’s discuss each of these areas and provide an example of a control that can be used for protecting resources.

Physical

The physical level of defense includes the actual hardware technology and spans the entire data center facility. This includes the compute, storage, and networking components, rack spaces, power, internet, and cooling. It also includes the room that the equipment is housed in, the building location and its surroundings, and the processes that are in place for the guards, physical security staff, or guests that access these locations.

Protecting the physical level of defense in depth encompasses how we create redundancy and resiliency in the previously mentioned systems, and how we record and audit who accesses the building and systems. This could include gated fences, guard stations, video surveillance, logging visitors, and background checks. These physical controls should be in place for any company that utilizes its own private data center.

When utilizing Microsoft cloud services, the physical controls are Microsoft’s responsibility. We will discuss shared responsibility for cloud security in the next section.

Identity and access

Since the provider is responsible for the physical controls within cloud services, identity and access become the first line of defense that a customer can configure and protect against threats. This is why statements such as “Identity is the new control plane” or “Identity is the new perimeter” have become popular when discussing cloud security. Even if your company maintains a private data center for the primary business applications, there is still a good chance that you are consuming a cloud application that uses your company identity. For this reason, having the proper controls in place, such as multi-factor authentication (MFA), conditional access policies, and Azure AD Identity Protection, will help to decrease vulnerabilities and recognize potential threats before a widespread attack can take place.

Perimeter security

Within a private data center, where the company controls the internet provider connection terminations and has their firewall appliances, intrusion detection and protection solutions, and DDoS protection in place and fully configured, the protection of the perimeter is a straightforward architecture.

When working within cloud providers, perimeter security takes on a different focus. The cloud providers have agreements with the internet providers that provide services to their data centers and these providers terminate these connections with their hardware. The company perimeter security then becomes more of a virtual perimeter to their tenant, rather than a physical perimeter to the data center network facilities. The company now relies on the provider’s ability to protect against DDoS attacks at the internet perimeter.

Within Microsoft, DDoS protection is a free service, since Microsoft wants to avoid a DDoS attack that would bring down a large number of their customers in a data center. For additional perimeter protection, the company can implement virtual firewall appliances to protect the tenant perimeter, to block port and packet level attacks, and additional solutions, such as Application Gateway, with a web application firewall (WAF) to protect from application layer attacks.

Network security

The perimeter and network security layers work closely together. Both focus on the network traffic aspect of the company infrastructure. Where perimeter security handles the internet traffic that is entering the tenant, or data center, network security solutions protect how and where that traffic can be routed once it passes through the perimeter. Once an attacker can gain access to a system on the network, they will want to find ways to move laterally within the network infrastructure. Having proper IP address and network segmentation on the network can protect against this lateral movement taking place.

On a private data center network, this can be accomplished within switch ports with virtual Local Area Networks (LANs), or VLANs, configured to block traffic between network segments. In a cloud provider infrastructure, virtual networking, or VNETs, can accomplish similar network segmentation. In an Azure infrastructure, network security groups and application security groups can also be configured on network interfaces with additional port, IP address, or application layer rules for how traffic can be routed within the network.

Compute

After network security, we begin to get into the resources that hold our data. The first of these is our compute resources. In order to maintain clarity, we will generalize the compute layer as the devices with an operating system, such as Linux or Windows. Compute resources also include platform-based services where the compute layer is managed by the cloud provider, such as Azure App Service, Azure Functions, or containers. Within your own private data center with equipment that you own, protecting the host equipment and avoiding exposure by hardening the virtual hypervisor is necessary. In the public cloud, Microsoft or another cloud provider will be responsible for this. Our responsibility on virtual machines relies on maintaining proper patching of updates and security, to avoid having exploit vulnerabilities within the operating system. In addition, encrypting virtual machine operating systems and disks with Azure Disk Encryption will protect the image from being exposed.

A common attack at the compute layer is scanning and gaining access to management ports on devices. Not exposing these ports, 3389 for Windows Remote Desktop Protocol (RDP) and 22 for Linux Secure Shell (SSH) Protocol, to the internet will provide a layer of protection against these attacks. Within Microsoft Azure, this can be accomplished with network security group rules, removing public IP addresses on virtual machines, bastion hosts, and/or utilizing just-in-time virtual machine access. Many of these security options will be discussed in Chapter 7, Designing a Strategy for Securing Server and Client Endpoints.

Applications

The layer of defense that is closest to our data is our applications. Applications present data to users through our internet websites, intranet sites, and our line of business applications that are used to perform our day-to-day business. A cybersecurity architect will determine how to protect applications against common threats, such as cross-site scripting on our websites. To protect against these common threats, a WAF can be used for proper evaluation of the traffic accessing our applications. Utilizing secure transport layer (TLS) protocols that are encrypted can also help to avoid the exposure of sensitive data to unauthorized individuals.

Prior to an application being moved to production, it should be properly tested to make sure that there are no open management ports and that all API connections are also secured.

If the application references connections to databases and storage accounts, the secrets and keys should not be exposed and a key management solution, such as Azure Key Vault, should be in place for the proper rotation of secrets, keys, and certificates. Properly securing these areas of our applications will assist in avoiding exposure of sensitive data to those that are not authorized.

Data

Always at the center of our defense-in-depth security posture is our data. Data is the primary asset of our company. This includes the business and financial data that is necessary for the company’s survival and the personal information of our employees and customers. Exposure or theft of this information would have potentially catastrophic effects on the company’s ability to continue. These effects could be reputational and involve financial loss.

As a security professional, one must protect data from intentional and accidental exposure to those that are not authorized to view it. Data resides in various areas within our technology infrastructure. Data can be found primarily in different storage accounts, such as blob containers or file shares, and within relational and non-relational databases. The common practice to accomplish this is through encryption.

Encryption makes data unreadable to those that are not properly authenticated and authorized to view it. Encryption can be used in different ways with data. First, there is encrypting data at rest, which is when it is stored and not being accessed. Next, there is encryption in transit, or while it is being delivered from where it is stored to the person requesting access. Finally, there is encryption in use, which maintains the encryption of the data within the application throughout the time that it is being viewed. This is the more complex of the types of data encryption since it requires the application to have the capability of presenting the encrypted data. Microsoft provides options for these encryption types that will be discussed later in this book.

Encrypting our data in our storage accounts and databases decreases the potential of this data being exposed to those that are not authorized. Additionally, requiring verification through authentication and authorization maintains the protection of data. This includes avoiding anonymous access to storage accounts and masking sensitive data within our databases. The most important aspect of protecting our data is knowing where our sensitive data is located and planning proper steps to avoid it being exposed to the unauthorized. Bringing together the protection of data within the entire defense-in-depth strategy provides us with an effective way to protect against vulnerabilities and threats.

Maintaining a proper security posture across all of the defense-in-depth layers is the best way to protect our company from loss or exposure across the stages of a cyber attack. These stages will be further discussed later in this chapter. As security professionals, it is important that we take ownership of the planning, execution, monitoring, and management of all of these layers and work with other stakeholders at each of these layers to maintain the overall security posture for the company.

Special considerations need to be accounted for within this security posture when utilizing public cloud services. In the next section, we will discuss how this shared responsibility for cloud services requires possible adjustments to our defense-in-depth security approach.

Shared responsibility in cloud security

As technology has evolved and more resources have a level of exposure to external internet connections, the attack surface that is potentially vulnerable also increases. We must understand this and know where our responsibilities lie for each of the areas within our defense-in-depth security approach.

Shared responsibility is the relationship between the customer and the cloud provider at each of the layers of defense in depth. This relationship differs depending on the technology that is being consumed.

Shared responsibility focuses on who has the ownership to interact at a specific level of protection. This may be physical ownership of equipment or administrative ownership for enabling various controls. The level of ownership between the company using the service and the cloud provider changes depending on the type of service that is being consumed by the company.

Table 1.1 shows shared responsibility for customers and Microsoft within the various cloud and on-premises services.

Table 1.1 – Shared responsibility in the cloud

As you look at the customer’s and Microsoft’s responsibilities for security, the cybersecurity architect should determine the levels of controls that the company should have in place for each of the areas of potential vulnerabilities and exposure to attacks.

The next section will build upon the areas of controls and security posture, and we will discuss the various components of cybersecurity operations.

Now that we understand security posture, defense in depth, and shared responsibility as we begin to architect cybersecurity for the cloud, we will discuss the makeup of a security operations team and the levels of a cybersecurity attack.

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’s 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 possibly 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 that are attempting to gain some level of control and do harm to the company that they are attacking.

Understanding the stages of a cyber attack

There are many ways that an attacker can attempt to access resources within the company. How they gain this access and what they attempt to accomplish once they gain access is the foundation of a cyber attack. Figure 1.2 shows the stages of a cyber attack in a linear format:

Figure 1.2 – Stages of a cyber attack

In many cases, an attacker is attempting to enter and do some level of damage at one of these stages. Sophisticated attackers may go through every one of these stages in order to gain full access to resources and increase the amount of damage that they can do to a company. Let’s define each of these stages for further understanding:

1. Reconnaissance: This is the planning stage of the attack. The attacker is gathering information that they can find about the company or companies that they will be targeting. This may be through social media, websites, phishing, or social engineering of personnel within the company. Another aspect of this stage is port scanning known management ports, such as RDP port 3389 or SSH port 22. The goal at this stage is to attempt to find ways to access systems.
2. Intrusion: Once the reconnaissance is successful, the attacker has found a way to access a system or systems within the company network. Now, they will use that knowledge to get into those systems. One type of intrusion is a brute-force attack.
3. Exploitation: The attacker has gained access to a system on the company network and now they want to exploit that system. This is where the attacker begins to show malicious intent. They will begin to use this access to deliver malware across the network.
4. Privilege Escalation: Once the attacker has gained access to a system, they will want to gain administrator-level access to the current resource, as well as additional resources on the network. If they have gained access to a virtual machine on the network, they could have administrative login privileges to other virtual machines and resources on the network.
5. Lateral Movement: Companies that use the same administrator username and password could allow the attacker to gain access to other systems across the network. This lateral movement could lead the attacker from a system without sensitive information to one that has extremely sensitive information.
6. Obfuscation/Anti-forensics: As is the case with any attack or crime, the person or people involved do not want to be found or traced. Therefore, they attempt to keep their access anonymous. If they have gained access through someone’s credentials within the company, this could help to decrease their traceability.
7. Denial of Service: When an attacker cuts off access to resources, this is a denial of service. This may be through an attack such as an SYN flood where they send a large number of requests to a company’s public IP address that cannot be processed fast enough. This flood of requests blocks legitimate requests from being able to access resources. Another means of denial of service could be a ransomware attack. This is not a typical blocking of information but more the withholding of information through encryption so that a company and its users can no longer access that information. The attacker then extorts the company for payment to make the information accessible.
8. Exfiltration: The final aspect of the cyber attack is exfiltration. This is where the attacker has gained access to sensitive information and they are able to take that information to do harm in some way. This could be banking information, personally identifiable information (PII) about personnel or customers, and other valuable data.

The ability to protect against each of these aspects of the cyber attack is our kill chain. Each of these areas becomes an area to focus on protecting with cybersecurity controls. Understanding vulnerable areas and the potential threats to them will allow you to determine ways to address and create a secure architecture.

Microsoft Defender for Cloud threat protection alert events are categorized based on the MITRE ATT&CK framework to understand and investigate potential attacks. Figure 1.2 shows this framework and the anatomy of an attack.

For more information on the MITRE ATT&CK framework, go to this link: https://attack.mitre.org/

In the next section, you will learn how to address the areas of cybersecurity in the cloud within the areas of shared responsibility and zero trust. You will also learn about some of the common attacks that you should be aware of when building a cybersecurity architecture.

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.

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:

https://cloudsecurityalliance.org/press-releases/2019/08/09/csa-releases-new-research-top-threats-to-cloud-computing-egregious-eleven/

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.

In this chapter, we have discussed multiple areas to consider as a cybersecurity architect within cloud and hybrid infrastructures. This included the variations in cybersecurity for on-premises data centers versus moving to cloud environments. As you move on to the next sections of this book and begin to determine how Microsoft capabilities can be used to design a cybersecurity architecture for a company, these concepts and topics will be important to reference.

The next chapter will discuss how to build an overall security strategy and architecture with a focus on the Microsoft Cybersecurity Reference Architectures.