Task – creating a new resource group that requires access
In the assigning with RBAC:resource group requiring access, creating” search bar, type resource groups; click Resource groups from the results list.
From the Resource groups blade, click + Create via the top toolbar.
From the Basics tab, set the Project and Resource details as required.
Click Next: Review + create.
On the Review + create tab, review your settings; you may go back to the previous tabs and make any edits if required. Once you have confirmed your settings are as required, you can click Create.
You will receive a notification that the resource group was created successfully.
Click Go to resource group from the Notifications blade. Alternatively, navigate to the resource group instance.
Task – assigning access to a resource group
From the created Resource groups blade, click Access control (IAM) from the left-hand side menu.
From the Roles tab, review the built-in roles; under the Details column, you can click on View to see the permissions that role will grant.
From the Role assignments tab, review the current assignments.
From the Check access tab, please review the options for My Access and Check access, and then click Add role assignment.
From the Role tab, click Owner or the role you wish to assign.
Click Next.
For this exercise, leave Assign access to set to the default of User, Group, or Service Principal.
From Members, select the members to be assigned the role.
Click Next.
Click Next: Review + assign.
You will receive a notification that the role assignment was added.
Click the Role assignments tab from the Access control (IAM) blade and review the new assignment that was created.
In this exercise, we successfully created a resource group and assigned the RBAC role to a user for access. In the following exercise, we will look at creating a custom RBAC role.
In this exercise, you’ll learn how to interact with Azure environments using the Azure CLI as the CLI tool and Cloud Shell as the shell environment for running commands.
The following subsections will show you how to create all the necessary resources for this exercise. These have been segregated into tasks for ease of understanding:
Task – setting up Cloud Shell (skip this task if you’ve already completed it)
2. Click on the Cloud Shell code icon on the top toolbar of the portal. If this is the first time you have used Cloud Shell and no storage has been mounted to persist files, you will be prompted to create a storage account. Select your subscription and then click on Create storage:
Figure 6.31 – Cloud Shell setup
3. Once the storage account has been created, you will be connected to a terminal running the shell environment you will use to run commands.
Task – creating a resource group
Bash should be set as the CLI within Cloud Shell for this exercise.
To create a resource group, enter the following command:
az group create -l uksouth -n Project1-RG
6. The output will look as follows:
Figure 6.32 – Creating a resource group
To show the resource group that has just been created, enter az group list or az group list –out table.
The created resource group will also appear in the portal UI.
Figure 6.33 – Showing the created resource group
Task – creating a virtual machine
9. To create a virtual machine, enter the following code:
az vm create \
–resource-group Project1-RG \
–name myVM \
–image win2019datacenter \
–admin-username azureuser
10. When prompted, enter a username and password:
Figure 6.34 – Creating a virtual machine
You will see a Running message while the virtual machine is being created.
Once the virtual machine has been created, the following information will be returned:
Figure 6.35 – Virtual machine created
13. To show the virtual machine that has just been created, enter the following command:
az vm list –out table
14. The created virtual machine will also appear in the portal UI.
Figure 6.36 – Showing the created virtual machine
In this exercise, we created a resource group and a virtual machine using the Azure CLI from Cloud Shell. The following exercise looks at using Azure Service Health in the Azure portal.
Attackers can take many forms, such as criminal hackers, hacktivists, competitors, and foreign nations. Don’t forget either that attackers are not only external; they can be internal to an organization—for example, ex-employees—these often being the hardest to detect and prevent. For further reading, you should enter Sly Dog gang into your favorite search engine to read about a real-world insider espionage attack on one of the highest-profile manufacturers of electric vehicles.
You must put in measures so that you don’t become an easy target for opportunists as well as the crafted, pre-meditated, military-style operation of some sophisticated attacks; these measures are designed to raise the attacker’s costs significantly, so they divert their resources and activities to an easier attack target that has a higher return on their attack investment.
The approach that should be taken is to adopt a threat priority model; this can then aid in identifying your threat priorities and where security investments should be made to reduce your costs of security operations and increase your attacker’s kill-chain costs. The following diagram aims to visualize this approach:
Figure 7.1 – Threat priority model
Any security approach must start from an inward look at your current security position and secure score. A secure score can be thought of like a credit-rating score you receive to see how likely you are to be accepted for a finance agreement, but in security terms, it looks at where you are on the attack vulnerability scale of 1 to 10, as it were; this score will indicate your security posture.
A security posture is an organization’s threat-protection and response capabilities; this ensures that an organization has the ability for systems, data, and identities to be recoverable and operational should an attack be successful. It is critical to understand that we cannot prevent or eliminate threats and attacks, and the fact is that an attacker only has to be successful once while you must protect everything, all the time. A security posture’s goal should be to reduce exposure to threats, shrinking attack surface areas and vectors while building resilience to attacks, as they cannot be eliminated.
A security strategy and security posture should use the guiding principles of Confidentiality, Integrity, and Availability, also referred to as the CIA triangle. There is no perfect threat prevention or security solution; there will always be a trade-off, and the CIA model is a way to think about that. The CIA model is a common industry model used by security professionals; it is not a Microsoft model. Let’s look at these guiding principles in more detail here:
Confidentiality—This is a requirement that sensitive data is kept protected and can only be accessed by those who should have access through the principle of least privilege (POLP). Confidentiality is about the confidence that the data cannot be accessed, read, or interpreted by anybody other than those intended to read and access this data; this can be achieved by encrypting the data. The encryption keys also need to be made confidential and available to those who need access to the data.
Integrity—This means that data transferred is the same as data received; the bytes sent are the same bytes received. Integrity is about the confidence that the data has not been altered from its original form or tampered with; this can be achieved by hashing the data. Malware can threaten the integrity of systems and data.
Availability—This means that data and systems are available to those that need them, including access to encryption keys, but in a secure and governed manner. Availability means a trade-off between the three sides of the triangle and a balance being made of being locked down for security but accessible for operational needs and productivity. A distributed-denial-of-service (DDoS) attack will threaten the availability of systems, data, and encryption keys.
The following screenshot represents the CIA triangle model:
Figure 7.2 – Security posture CIA triangle
The aim of an attack may be specific to an organization and may be different based on the form of the attacker—such as a criminal hacker, a foreign nation, a hacktivist, an opportunist, and so on. The aim may be to steal data, deface a website, alter the integrity of an app or a service, extort money through ransom, and so on.
There are two motivations of attackers, money or mission. The motivation is clearer for money-driven attacks and has a certain level of calculation by the attacker on their return on investment (ROI) before they give up and move on to another target. However, for mission-driven attacks, the rationale may be more opaque and less tangible of what is to be gained, and a mission attack is often more of a moral standard and a matter of ethics, principles, politics, and control than money. Thus, the attacks may be more sustained and the attackers determined to succeed at any cost, because the reward may not have a price that can be attached. The following diagram aims to visualize this approach:
Figure 7.3 – Attack motivations
We have learned about the types of attackers and their motivations; the following are some of the most common threats to protect against:
Ransomware—This is malware that will encrypt files and folders in an attempt to extort money.
Data breach—This includes phishing, spear phishing, Structured Query Language (SQL) injection, stealing passwords/bank details/other sensitive information, luring somebody to click a link, and opening a file.
Dictionary attack—This is an identity-theft attack, also known as a brute-force attack; known passwords are used against an account to steal an identity.
Disruptive attack—This is a network and workload attack; a DDoS attack attempts to make a network or workload unavailable by flooding it with requests and attempting to exhaust its resources.
Attackers plan and structure their attacks; this is so they can live undetected on the network and in the user’s systems without the victim being alerted. As the adage says, there are two types of organizations: those who have been compromised and those who don’t know yet.
Attacks follow a sequence or chain of events; this is known as an attack chain or a kill chain. The following diagram shows a common chain:
Figure 7.4 – Attack chain
When a user account is compromised, it can access the network and then work to elevate privileges to an admin account that can then move laterally within the network to access the data and execute activities such as steal, delete, corrupt, and encrypt data.
Through a Zero Trust and DiD approach to protecting assets, the goal is to prevent and disrupt this chain of events; we want to put multiple obstacles in the attacker’s way and increase their attack costs so that they will move on to launching an easier attack elsewhere that offers less resistance.
Security can often be seen as the anti-pattern of operations, availability, and productivity; you may have encountered overzealous security teams referred to as business prevention teams. Much as there have been silos and cultural divides between development and operations teams, there is often a divide between security and these teams.
Often, the feeling is that it’s the security team’s job to make things secure and protect code, data, systems—a not my job attitude, throwing it over the wall in an it’s the security team’s problem now culture.
Security must be in place before a single line of code is written, a system created, or data stored; a culture akin to Development-Operations (DevOps) of fostering trust between all teams and security teams must exist, and leaders must bring the notion and culture of Security-Development-Operations (SecDevOps) into an organization.
The bottom line is that security is not just somebody else’s problem, but everybody’s responsibility; and as they say… if you are not part of the solution, you are part of the problem.
An important concept to consider is Zero Trust, which uses the approach of never trust, always verify; this concept relates to thinking beyond traditional network perimeter-based security and adopting a holistic approach to security.
Zero Trust is not a service or solution but a wider-thinking security strategy and framework to be adopted, and works on the notion of ensuring compliance and securing access at the resource and no longer the location or network the resource is on; we must NOT assume trust because of the resource’s network or location.
The Zero Trust framework is built upon the following foundational principles:
Assume breach.
Verify explicitly.
Use least-privilege access (Just In Time (JIT), and just enough access).
In this new world of hybrid work where organizations’ traditional firewalls and security service-controlled network perimeters have vanished due to remote working, we must now consider identity as the new perimeter. The following are the Zero Trust framework’s six foundational elements:
Identities—Users, services, devices; each represents an element to be compromised
Devices—Represent an attack surface and threat vector for data flows
Applications—Represent the consumer of the data flows
Data—Represents the data stored that is to be protected
Infrastructure—Represents an attack surface and threat vector, whether locally on-premises or remotely hosted by a cloud provider
Network—Represents an attack surface and threat vector and should be segmented
In this section, we introduced the concept of the Zero Trust framework. The following section looks at the concept of DiD.
Defense in depth
DiD refers to a strategy that places multiple layers of different forms of defenses between attackers and the resources you are trying to protect.
Adopting a DiD strategy allows an organization to adopt a strong security posture and help ensure that all systems, data, and users are better protected from threats and compromise.
A DiD strategy means there is no single layer of protection or security service that is solely responsible for protecting resources, but by implementing many different types of defense at individual layers, you can slow down an attack path. It may successfully breach one defensive layer but be halted by subsequent protection layers, preventing the protected resource from being exposed.
The following screenshot shows that DiD as a concept is nothing new as a strategy; it can be considered the medieval castle concept of protecting resources:
Figure 7.5 – Medieval castle defense approach
The medieval castle approach should be part of your strategy for building your resources in Azure; you define multiple layers that can be protected by different security services that are the most appropriate at each layer.
As with our medieval castle analogy, each layer from the center to the outside to the center provides its own independent protection service, tailored to best protect the characteristics of that layer.
The following diagram aids in visualizing the layers that make up a DiD strategy for a resource to be protected:
Figure 7.6 – DiD approach layers
There is no one-size-fits-all security service that can protect all the layers; however, we must have security services at each layer that work in conjunction and complement the layers outside and inside of their layer. There must be a single unified view so that telemetry and threat intelligence can be passed between each layer and enhance the protection at each layer. Microsoft uses artificial intelligence (AI), threat intelligence, and analytics to enhance these capabilities. In this section, we looked at adopting a DiD strategy. The following section looks at network and application protection.
Azure Blueprints is much the same as we can think of blueprints outside of a technology discussion; it provides patterns, designs, and definitions for creating something. We can think of this along the lines of a blueprint for a house, a car, a space rocket, and so on; an Azure blueprint is no different from this concept.
An Azure blueprint is a package or representation of a collection of defined, prescribed, repeatable resources to be deployed that conform to an organization’s governance standards and patterns when implemented. This allows governance and design parameters to be defined that rapidly allow teams to repeatedly stand up projects and initiatives within the blueprint’s control.
Azure blueprints can be created through the Azure portal, Azure PowerShell, the Azure CLI, ARM templates, or the REST API; blueprint definitions are saved to a management group or subscription, which requires contributor access.
Blueprints are represented as objects and are replicated to multiple Azure regions so that they can always be accessed from whichever region you wish to deploy resources to. This allows you to create repeatable environments that use the same defined artifacts each time across all subscriptions.
One blueprint can be assigned to govern several subscriptions, so they always have the same definitions; blueprints are assigned to the management or subscription level.
A blueprint is made up of a blueprint definition (what should be deployed) and a blueprint assignment (where is it being deployed). It is composed of artifacts, and the blueprint can be thought of as the container, package, or scaffolding, as it were. The following diagram aims to visualize the concepts of Azure Blueprints:
Figure 9.5 – Azure Blueprints
In summary, Azure Blueprints allows governed environments to be quickly and repeatably deployed across subscriptions to a governed resources standard using a set of composed artifacts.
In this section, we looked at Azure Blueprints. In the next section, we’ll look at the CAF for Azure.
