Chapter 1 The threat landscape

On May 12, 2017, the mainstream media began covering a massive ransomware attack called WannaCry, catching the world by surprise. It was reported that in a single day, 230,000 computers in more than 150 countries were infected. The attack was carried out by exploiting computers on which the MS17-010 patch—released in March 2017 to fix a Microsoft SMB vulnerability—had not been applied. In addition to affecting home users, this attack hit organizations such as the United Kingdom’s National Health Service (NHS). Computers that were patched were not affected. (This of course highlights the need to have a solid update-management process in place!)

Ransomware like WannaCry—or like Petya, which allows for lateral movement (meaning it takes only a single infected machine to potentially bring down the entire network)—is just one threat in the current landscape. There are many others. Before we dive into Azure Security Center, you need a good understanding of current threats and the motivations of the people behind them. Current threats range from old but effective techniques such as phishing emails to state-sponsored attacks and everything in between. For example, one common threat is drive-by download sites. Another is Trojans. Then there is the weaponization of cloud resources to attack on-premises assets. This chapter explores several of these threats to prepare you to use Azure Security Center. But first, it discusses cybercrime and the cyber kill chain, establishing your security posture, and the assume-breach approach.

Understanding cybercrime

The days of hacking for status are behind us. Nowadays, a main motivator behind cyberattacks is some sort of financial gain.

The Internet Crime Complaint Center (IC3) is part of the Cyber Division of the US Federal Bureau of Investigation. According to its 2016 Internet Crime Report (https://pdf.ic3.gov/2016_IC3Report.pdf), the IC3 received 2,673 complaints related to ransomware, resulting in losses of more than $2.4 million. Tech-support fraud also left a mark, with a total of $7.8 million in losses in 2016. Finally, the total financial loss in the United States exceeded $1.3 billion in 2016—up 24 percent from the previous year.

You’re probably wondering how cybercriminals monetize the data they steal. That’s a great question. Many of these cybercriminals work in organized crime. They have a globally distributed criminal infrastructure, which is used to launch attacks. Before they launch an attack, they start a new attack campaign. To build that campaign, they work with technically sophisticated organized crime groups, which they find on the cybercriminal marketplace online.

These technical cybercriminals have different online offerings. For example, they might offer counter-antivirus (CAV) services, which scan antivirus engines to make sure new malware can be successfully deployed without being detected. Another offering could be bulletproof hosting services for online criminal activity. (They’re called “bulletproof” because the owners of these servers do not cooperate with local enforcement in case of an investigation.) There are even escrow services that act as a third party in online transactions between technical criminals and their criminal clients.

Understanding the cyber kill chain

One of the most challenging aspects of defending your systems against cybercriminals is recognizing when those systems are being used for some sort of criminal activity in the first place—especially when they are part of a botnet. A botnet is a network of compromised devices that are controlled by an attacker without the knowledge of their owners. Botnets are not new. As a matter of fact, a 2012 Microsoft study found that cybercriminals infiltrated unsecure supply chains using the Nitol botnet, which introduced counterfeit software embedded with malware to secretly infect computers even before they were purchased. (For more information, see https://aka.ms/nitol.)

The best way to prevent this type of attack, or any other, is to identify attack vectors—that is, how an attacker will attack your environment. To help with this, Lockheed Martin developed a cyber kill chain. Each step in this chain represents a particular attack phase. (See Figure 1-1.)

FIGURE 1-1 Typical location where QKSee is installed.

The steps in this chain are as follows:

1. External recon During this step, attackers typically search publicly available data to identify as much information as possible about their target. The goal of this step is to obtain intelligence, or intel, to better perform the attack and increase the likelihood of success.

2. Compromised machine During this step, attackers leverage different techniques, such as social engineering, to entice users to do something. For example, the attacker might send a phishing email to lure the user into clicking a link that will compromise the machine. The goal is to establish a foothold on the victim’s network.

3. Internal recon and lateral movement During this step, the attacker performs host discovery and identifies and maps internal networks and systems. The attacker may also start moving laterally between hosts, looking for a privileged user’s account to compromise.

4. The low-privileges lateral movement cycle During this cycle, the attacker continues to search for accounts with administrative privileges so that he or she can perform a local privilege escalation attack. This cycle typically continues until the attacker finds a domain administrative user account that can be comprised.

5. Domain admin creds At this point, the attacker needs complete domain dominance. To achieve this, the attacker will pivot through the network, either looking for valuable data or installing ransomware or any other malware that can be used for future extortion attempts.

Common threats

As mentioned, one common type of attack is the use of drive-by download sites. These are websites that host one or more exploits that target vulnerabilities in web browsers and browser add-ons. According to Microsoft Security Intelligence Report volume 22, Bing detected 0.17 drive-by download pages for every 1,000 pages in the index in March 2017.

According to the same report, in the first quarter of 2017, Trojans were the most commonly encountered type of malicious software (followed by worms and droppers). Trojans always pose as a useful application. For example, take the Win32/Xadupi Trojan, also called WinZipper (%ProgramFiles%WinZipper) or QKSee (%ProgramFiles%qksee). In addition to creating a shortcut to itself in the Start menu (see Figure 1-2), enabling users to zip and unzip files, this Trojan also creates a service (qkseeService) that connects to command and control (C2) servers and periodically checks for instructions using HTTP requests. Often, these instructions are to silently download new files, which could contain malware that will be executed on the local computer. This is just one example of how threats spread.

FIGURE 1-2 The cyber kill chain.

These days, the end user is almost always the target, since he or she is the weakest link. With the proliferation of mobile devices, bring-your-own-device (BYOD) models, and cloud-based apps, users are installing more and more apps. All too often, these apps are merely malware masquerading as valid apps. Many do something similar to (or even worse than) what QKSee does. For this reason, it is important to have in place not only good endpoint protection but also a detection system that can look across different sources to intelligently identify unknown threats by leveraging cutting-edge technologies such as analytics and machine learning.

Building a security posture

It used to be that cybersecurity experts recommended that organizations simply invest more in protecting their assets. Nowadays, however, simply investing in protecting your assets is not enough. Instead, organization should invest in building a solid security posture. As shown in Figure 1-3, a security posture is composed of three major pillars.

FIGURE 1-3 The three pillars of a security posture.

According to the InfoSec Institute, attackers lurk on networks for an average of 200 days without being detected. (See http://resources.infosecinstitute.com/the-seven-steps-of-a-successful-cyber-attack for more information.) No doubt, this is a huge amount of time to have an attacker inside your network. But the key word here is actually detected. Without a good detection mechanism, you have no way to disrupt an attack. Hence, it is imperative to invest in a holistic solution to monitor cloud-based resources as well as on-premises assets. You must be able to quickly detect an attack and to use actionable data to improve your response. All that being said, collecting data without analyzing it only delays the response process. That’s why it is so important to use tools that leverage technologies such as behavior analytics, threat intelligence, and machine learning for data correlation. Azure Security Center will do all that for you, reducing false positives and showing what’s relevant for you to proceed on your investigation.

Adopting an assume-breach mentality

Microsoft recognizes that it’s not enough to prevent a breach. You must adopt an “assume-breach” mentality. When you adopt an assume-breach mentality, it means you hope that you will never be breached but you assume that you have been breached or will be soon. Then you gather the people, processes, and technology that will help you find out when a breach occurs as early as possible, discover which breach has occurred, and eject the attacker while limiting the effects of the breach as much as possible.

Taking an assume-breach approach helps you understand how attackers gain access to your system and helps you develop methods that enable you to catch the attacker as soon as possible after a breach takes place. Because attackers typically enter a system via a low-value target, if you can quickly detect when such a target has been compromised you can block the attacker from expanding to higher-value assets, which are the ultimate target.

One very effective method for doing this is through red/blue team simulations. In these exercises, the red team takes on the role of the attacker and the blue team takes on the role of a defender. To begin, you define the parameters of the exercise, including the duration. Then, the red team tries to attack your system—in this case, your Azure infrastructure. At the same time, the blue team tries to detect what the red team is doing and, if the red team manages to compromise any systems, to block the red team from compromising additional assets. At the end of the exercise, members of the red and blue teams discuss what happened, how the red team might have gotten in, and how the blue team detected and ejected the red team, and suggest technologies and operational procedures to detect attacks more quickly and easily.

Cloud threats and security

One threat is the weaponization of cloud resources to attack on-premises assets. In a typical cloud-weaponization scenario, the attacker compromises and takes control of one or more virtual machines (VMs). From there, the attacker launches attacks on other cloud or on-premises resources, including brute-force attacks and email phishing attacks. The attacker may also conduct reconnaissance—for example, port scanning to identify new targets. Figure 1-4 shows an attacker gaining access to VMs located in the cloud and leveraging compute resources from these VMs to attack on-premises assets. This is a typical cloud-weaponization scenario.

FIGURE 1-4 A cloud-weaponization scenario targeting on-premises resources.

Another potential cloud threat occurs due to flaws during configuration and DevOps. One common scenario involves the public key secret shared in a public cloud. Such an event occurred in 2015, when bots scanned GitHub to steal Amazon EC2 keys. Figure 1-5 illustrates this scenario. (For more information, see https://www.theregister.co.uk/2015/01/06/dev_blunder_shows_github_crawling_with_keyslurping_bots/.)

FIGURE 1-5 Public secret attack scenario.

Before adopting cloud computing, organizations must understand the security concerns inherent in the cloud-computing model. Ideally, these concerns should be addressed during the planning process. (Depending on what type of organization you’re dealing with, some of these concerns may require more attention than others.) The concerns are as follows:

Compliance

Risk management

Identity and access management

Operational security

Endpoint protection

Data protection

The following sections describe these concerns in more detail.

Compliance

During and after migration to the cloud, organizations must continue to meet their compliance obligations. These obligations could be dictated by internal rules or by external regulations, such as industry standards.

Cloud solution providers (CSPs) must be able to assist customers in meeting these compliance requirements. Indeed, in many cases CSPs become part of the organization’s chain of compliance. Work closely with your CSP to identify your organization’s compliance needs and to determine how the CSP can meet them. Also verify that the CSP has a proven record of delivering reliable cloud services while keeping customer data private and secure.

Risk management

Cloud customers must be able to trust the CSP with their data. CSPs should have policies and programs in place to manage online security risks. These policies and programs may vary depending on how dynamic the environment is. Customers should work closely with CSPs and demand full transparency to understand risk decisions, how they vary depending on data sensitivity, and the level of protection required.

Identity and access management

Organizations planning to adopt cloud computing must be aware of the identity- and access-management methods available and of how these methods will integrate with their current on-premises infrastructure.

These days, with users working on different devices from any location and accessing apps across different cloud services, it is critical to keep the user’s identity secure. Indeed, with cloud adoption, identity becomes the new perimeter—the control panel for your entire infrastructure regardless of the location, be it on-premises or in the cloud. You use identity to control access to any services from any device, and to obtain visibility and insights into how your data is being used.

As for access management, organizations should consider auditing and logging capabilities that can help administrators monitor user activity. Administrators must be able to leverage the cloud platform to evaluate suspicious logon activity and to take preventive actions directly from the identity-management portal.

Operational security

Organizations migrating to the cloud should evolve their internal processes, such as security monitoring, auditing, incident response, and forensics, accordingly. The cloud platform must enable IT administrators to monitor services in real time to observe the health conditions of these services and provide capabilities to quickly restore services that were interrupted. You should also ensure that deployed services are operated, maintained, and supported in accordance with the service level agreement (SLA) established with the CSP.

Endpoint protection

Cloud security is not only about how secure the CSP infrastructure is. It is a shared responsibility. One aspect of security for which organizations are responsible is endpoint protection. Organizations that adopt cloud computing should consider increasing endpoint security, as these endpoints will be exposed to more external connections and will access apps that may be housed by different cloud providers.

Users are the main target of attacks, and endpoints are the devices employed by users. An endpoint might be a user’s workstation, a user’s smartphone, or any other device that can be employed to access cloud resources. Attackers know that the end user is the weakest link in the security chain, and will continue to invest in social-engineering techniques, such as phishing emails, to entice users to perform actions that can compromise an endpoint.

Data protection

With regard to cloud security, the goal when migrating to the cloud is to ensure that data is secure no matter where it is located. Data might exist in any of the following states and locations:

Data at rest in the user’s device In this case, the data is located at the endpoint, which can be any device. You should always enforce data encryption at rest for company-owned devices and in BYOD scenarios.

Data in transit from the user’s device to the cloud When data leaves the user’s device, you should ensure that the data is still protected. There are many technologies that can encrypt data regardless of its location—for example, Azure Rights Management. It is also imperative to ensure that the transport channel is encrypted. Therefore, you should enforce the use of Transport Layer Security (TLS) to transfer data.

Data at rest in the cloud provider’s datacenter When data arrives at the cloud provider’s servers, their storage infrastructure should ensure redundancy and protection. Make sure you understand how your CSP performs data encryption at rest, who is responsible for managing the keys, and how data redundancy is performed.

Data in transit from the cloud to on-premises In this case, the same recommendations specified in the “Data in transit from the user’s device to the cloud” bullet apply. You should enforce data encryption on the file itself and encrypt the transport layer.

Data at rest on-premises Customers are responsible for keeping their data secure on-premises. Encrypting at-rest data at the organization’s datacenter is a critical step to accomplish this. Ensure that you have the correct infrastructure to enable encryption, data redundancy, and key management.

Azure Security

There are two aspects of Azure Security. One is platform security—that is, how Microsoft keeps its Azure platform secure against attackers. The other is the Azure Security capabilities that Microsoft offers to customers who use Azure.

The Azure infrastructure uses a defense-in-depth approach by implementing security controls in different layers. This ranges from physical security, to data security, to identity and access management, and to application security, as shown in Figure 1-6.

FIGURE 1-6 Multiple layers of defense.

From the Azure subscription-owner perspective, it is important to control the user’s identity and roles. The subscription owner, or account administrator, is the person who signed up for the Azure subscription. This person is authorized to access the Account Center and to perform all available management tasks. With a new subscription, the account administrator is also the service administrator and inherits rights to manage the Azure Portal. Customers should be very cautious about who has access to this account. Azure administrators should use Azure’s role-based access control (RBAC) to grant appropriate permission to users.

Once a user is authenticated according to his or her level of authorization, that person will be able to manage his or her resources using the Azure Portal. This is a unified hub that simplifies building, deploying, and managing your cloud resources. The Azure Portal also calculates the existing charges and forecasts the customer’s monthly charges, regardless of the amount of resources across apps.

A subscription can include zero or more hosted services and zero or more storage accounts. From the Azure Portal, you can provision new hosted services, such as a new VM. These VMs will use resources allocated from compute and storage components in Azure. They can work in silos within the Azure infrastructure or they can be publicly available from the internet. You can securely publish resources that are available in your VM, such as a web server, and harden access to these resources using access control lists (ACLs). You can also isolate VMs in the cloud by creating different virtual networks (VNets) and controlling traffic between VNets using network security groups (NSGs).

Host protection

When you think about protecting VMs in Azure, you must think holistically. That is, not only must you think about leveraging built-in Azure resources to protect the VM, you must also think about protecting the operating system itself. For example, you should implement security best practices and update management to keep the VMs up to date. You should also monitor access to these VMs.

Some key VM operations include the following:

Configuring monitoring and export events for analysis

Configuring Microsoft antimalware or an AV/AM solution from a partner

Applying a corporate firewall using site-to-site VPN and configuring endpoints

Defining access controls between tiers and providing additional protection via the OS firewall

Monitoring and responding to alerts

Network protection

Azure virtual networks are very similar to the virtual networks you use on-premises with your own virtualization platform solutions, such as Hyper-V or VMware. Azure uses Hyper-V, so you can take advantage of the Hyper-V virtual switch for networking. You can think of the Hyper-Virtual switch as representing a virtual network interface to which a VM’s virtual network interface connects. Figure 1-7 illustrates how Azure virtual networks are distributed in a multi-tenant environment.

FIGURE 1-7 The Azure network provides isolation even within the same tenant virtual network.

One thing in Azure that might be different from what you use on-premises is how it isolates one customer’s network from another’s. On-premises, you might use different virtual switches to separate different networks from each other. That’s perfectly reasonable. You can do that because you control the entire network stack and the IP addressing scheme on your network, as well as the entire routing infrastructure. Azure can’t give each customer that level of control, because it needs to reuse the same private IP address space among all the different customers, and it can’t tell each customer what segment of the private IP address space to use for their VMs. It can, however, apply isolation between tenants to better manage the private IP space.

Network access control is as important on Azure virtual networks as it is on-premises. The principle of least privilege applies both on-premises and in the cloud. One way to enforce network access controls in Azure is by taking advantage of NSGs. An NSG is equivalent to a simple stateful packet-filtering firewall or router, similar to the type of firewalling done in the 1990s. (I say this not to be negative about NSGs, but to make it clear that some techniques for network access control have survived the test of time.)

Storage protection

Azure Disk Encryption is a technology that enables you to encrypt the VM disk files for your Azure VMs. Azure uses Windows Hyper-V as its virtualization platform, so the VMs you run on Azure use the VHD file format. With Azure Disk Encryption, you can encrypt both the operating system VHD and any data disk VHD files that you have attached to your VMs. Figure 1-8 shows the encryption options for the various Azure services that use storage.

FIGURE 1-8 Encryption options in Azure.

Keep in mind that if an attacker somehow manages to access and copy your VM disk files, he or she would not be able to mount them. This is because the disks are encrypted, and the attacker likely does not have the key required to decrypt them. Microsoft recommends that you use this powerful security technology on any VM you run on Azure. You should use similar technology on any VMs you run on-premises as well.

Another option is to use Azure Storage Service Encryption (SSE) for data at rest. This service helps you protect your data. When you use this feature, Azure Storage automatically encrypts the data prior to persisting to storage and decrypts it prior to retrieval. The encryption, decryption, and key-management processes are totally transparent to users.