Identifying and valuing information assets

Companies often generate vast amounts of data, which conform to various levels of sensitivity. It is usually not practical for an organization to implement the ultimate level of security over all their data, so it is necessary to classify the information according to its function and value. Therefore, the risk management process should begin with an inventory of the organization’s information assets and a determination of each asset’s value to the company, taking into account its need for confidentiality, integrity, and availability. The factors to consider when compiling such an inventory are shown in Table 3-1.

The definitions used for information types will be specific to the nature of the business, as will their value to the business. For example, in the case of a company that uses its website to provide support information to customers, an attack that renders the site unavailable for several days would be an inconvenience. For a company that sells its products exclusively on the web, however, the unavailability of its e-commerce website for several days could be disastrous.

For a large enterprise, this type of asset inventory is typically not the exclusive province of the IT department. It will likely require the involvement of personnel from various departments and at various levels of the organization, including management, legal, accounting, and even clients and partners outside the company.

The value of an information resource might not necessarily be expressed in monetary terms. The result of a data threat might be lost productivity, the creation of additional work to restore or re-create the data, fines or penalties to government or regulating agencies, or even more intangible effects, such as bad public relations or lost customer confidence.

To quantify the inventoried assets, the best practice is to create a graduated scale that considers all the risk factors particular to the business. A general numerical scale from 1 to 3 or a risk gradation of low, medium, or high would work, with a larger number of grades if the security measures the administrators choose to implement warrant it.

The value or sensitivity of a data asset will determine the nature of the security mechanisms administrators use to protect it. Some types of data might be subject to legal or contractual compliance specifications, which impose strict limits on where and how they are stored and who can access them. The security requirements for this most sensitive data might define the highest value on the risk scale, which can call for extreme security measures such as on-premises storage in a secured data center, data encryption and redundancy, and highly restricted access permissions.

Other types of sensitive data might not even be subject to broadly categorical security mechanisms, such as those applied to file folders or specific file types. Microsoft 365 includes the Azure Information Protection (AIP) tool that can apply labels to documents containing sensitive information. Administrators can configure the labels to trigger various types of security, such as watermarks, encryption, and limited access. While users and administrators can manually apply the labels to documents, AIP is also capable of detecting sensitive information in documents and automatically applying labels to them. For example, when a user creates a Word document, administrators can configure AIP to detect values that appear to be credit card numbers, as shown in Figure 3-3, and apply a label to the file that calls for a specified degree of protection.

Data that does not greatly threaten confidentiality, integrity, and availability is at the low end of the risk scale. This data will require some protection, but the security at the low end of the scale might be limited just to file system access permissions.

Inventorying hardware

Once the data sensitivity and the value of the data has been assessed, the next step of the risk management plan design process is to consider the technology used to store, access, transmit, and process that data. This includes the servers or cloud services where the data is stored when at rest, the client systems and devices used to access the data, the network components that carry the data between the various systems, and the applications that process the data.

In the same way that the data itself is inventoried in the previous phase, there should be an inventory of all the hardware involved in the storage of the data. This information can be used to locate the precise source of a security breach and to help prevent unauthorized devices from accessing secured company resources.

The primary storage locations for all sensitive company information should be servers located in a secured environment, such as a data center or server closet, or a cloud service, which should have its own security policies detailed in the service contract. However, the process of compiling an inventory of client systems and devices can be significantly more complicated. Workstations located at the enterprise sites are presumably already inventoried, but home computers and employees’ mobile devices, such as smartphones and tablets, need to be considered. Also, computers and devices belonging to people outside the organization, such as partners, consultants, temporary workers, and customers, need to be considered.

Administrators should document every device that comes into contact with company data. The inventory should include information such as the following:

• Make The manufacturer of the device

• Model The manufacturer’s model name and number for the device

• Serial number The manufacturer’s serial number for the device

• Owner The person or organization that is the owner of the device

• User The person or persons who use the device to access company data

• Location The place where the device is installed or if mobile, the location of the person responsible for it

• Service ID The owner organization’s assigned ID number, if applicable

• Operating system The operating system installed on the device

• OS version The version and build of the operating system running on the device

• Network provider The provider used by the device to access the Internet or the company network

• Applications The applications on the device that are used to access company data

• Information used The specific types of company data that the device can access

For workstations owned by the organization, this information is typically compiled during the system’s deployment process and can probably be imported into the inventory. For systems and devices owned by employees, the information-gathering process should be required before any access to sensitive company data is permitted.

Verification of the inventory information can be difficult for users who are frequent travelers or home computer users, but in the modern management model implemented by Microsoft 365, tight control of hardware devices is an essential element of enterprise security. For devices owned by people who are not employees of the organization, such as customers, the diplomatic aspects of enforcing these policies can be even more difficult, but administrators might be able to mitigate them by creating a risk level that provides these users with access only to a limited class of information that is not extremely sensitive.

In addition to the systems and devices that access company data, networking technology can also present an element of risk. The most obvious potential attack vector is wireless network devices, which are vulnerable to outside attacks in a variety of ways. Microsoft 365 includes Microsoft Intune, which enables administrators to create Wi-Fi network profiles that contain preshared keys and other security measures that prevent unauthorized devices from connecting to a company wireless network. There are also some extremely sensitive data types that can require special handling even for wired networks, such as compliance regulations that require network cables to be enclosed in sealed conduits for protection against wiretapping. Hardware-based security devices, such as firewalls, should also be included in the inventory.

When hardware that accesses sensitive information is compromised, the data is presumed to be compromised as well. Administrators can use the hardware inventory to ensure that the operating systems and applications on the devices are kept up to date with security patches and that antivirus and other security tools are updated. Administrators can also use Microsoft 365 tools to create compliance policies so that devices cannot access network resources unless they meet specific requirements, including up-to-date software.

The hardware security elements of a risk management plan can go beyond the capabilities of the tools in Microsoft 365. Protecting the hardware can include other mechanisms, including the following:

• Physical security Software-based security measures cannot fully protect the data stored on a computer if intruders have physical access to the machine. Even if the intruders can’t compromise the data, they can always destroy it, which can be just as damaging to the organization. Physical measures, even those as simple as a locked door, are basic elements of any risk management plan. For mobile devices, which are always vulnerable to loss or theft, administrators can use Microsoft Intune mobile device management to implement the ultimate hardware solution: remotely erasing the data from the device.

• High availability In addition to malicious or criminal intrusion, hardware devices are also liable to failures from wear and tear or destruction from natural disasters, such as fires, earthquakes, and extreme weather. High-availability measures, such as RAID arrays, redundant servers, and duplicate data centers, can preserve data against loss and ensure that the data remains available to users. For Microsoft 365 data stored in the cloud, the Microsoft Global Network maintains data centers at locations throughout the world, as shown in Figure 3-4, providing subscribers with a 99.9 percent availability rate.

• Disaster recovery Data backups and cloud synchronization can enable sensitive data to be restored, even after an attack or a disaster renders the original data or the hardware on which it is stored unusable.

Classifying users

The third element of the digital estate that must be considered when creating a risk management plan is the people who actually access the data. Users, whether deliberately or inadvertently, are a constant vulnerability—if not an actual threat—to the organization’s data. After quantifying the organization’s information assets and their value and after inventorying the hardware used to store, access, transmit, and process the information, the next step is to list the people who have access to the information.

The people with access to the organization’s information certainly include employees who are authorized to create, view, and modify the data. However, a risk management team must consider the possibility of other individuals accessing the data as well. Anyone with physical access to computers on which data is stored or from which it is accessible is a potential threat. This includes cleaning and maintenance staff, repair people, and even security guards. Even if an individual doesn’t have the credentials needed to sign on to a computer, it is still possible for a person to steal or destroy the computer or remove a hard drive from it.

A risk management plan should include a list of everyone who has access to sensitive information and what exact information they can access. Access control policies should be designed to provide users with permissions only for the data they need and no more. Within the organization, administrators often do this by defining roles, granting the roles access to the required data, and then assigning individuals to those roles. This simplifies the process of authorizing new users, moving users to other jobs, and deauthorizing departing users. Administrators can then create an orderly lifecycle for each individual user’s identity, as shown in Figure 3-5.

Every person who is granted access to company data should have an individual user account, including people who are working on-site temporarily. Any convenience that might be realized by creating generic guest accounts and assigning them to temporary users as needed will be nullified by the difficulty these accounts can cause when investigating an incident involving data loss or unauthorized access.

The plan must also include the means of ensuring that the individuals signing on to computers are actually the people they purport to be. Password policies can ensure that users create passwords that are sufficiently long and complex and change them regularly. Microsoft 365 also includes several enhanced authentication mechanisms, including multifactor authentication options calling for a fingerprint scan or a code sent to a mobile phone in addition to a password.

Users with administrative privileges present a greater potential threat to company data. The risk management plan should include policies that require administrators to use standard user accounts for all typical work functions and administrator accounts only for tasks that require the additional privileges. This not only helps to protect the company data from accidental damage or deletion, but it also reduces the possibility of unauthorized software installation, whether intentional or not. Privileged access user accounts should have their own lifecycle policies with more stringent monitoring and control, as shown in Figure 3-6.

Of course, even authorized users can be a threat, and the risk management plan should define the specific means by which new employees are vetted, which should include national (or international) background checks, credit histories, and confirmation of degrees and other credentials. For organizations working with data that is extremely sensitive, more extensive investigation of new hires might be in order.

Internal users are a major source of security incidents, although the incidents can be unintentional as well as deliberate. Disgruntled workers and industrial espionage are certainly legitimate causes of data theft or loss, but simple slips, such as leaving a signed-on computer unattended, can be equally dangerous. In addition to addressing malicious threats, a risk management plan should devote sufficient attention to accidental threats.

Anticipating threats

Arguably, the most difficult part of the risk management planning process is trying to anticipate all the possible threats that could afflict the company data in the future. The three basic risk factors for the data—confidentiality, integrity, and availability—can be exploited in any number of specific ways, but the general threat categories are listed in Table 3-2.

The core of the risk management process is to anticipate potential threats in detail and use the information gathered earlier in the data, hardware, and user inventories to estimate the severity and likelihood of each threat. For example, the threat of the company’s client sales figures being disclosed when a travelling user misplaces his smartphone is far more likely than the threat of a competitor breaking into the company headquarters at night and hacking into a workstation to steal the same information. The severity of the threat in the two scenarios is the same, but the loss of a smartphone is the more likely occurrence, so administrators should expend a greater effort at mitigating that possibility.

In another example, a competitor’s burglary attempt might result in the theft of those same client sales figures; in another scenario, this same burglary attempt might cause deliberate damage to the company’s web servers, taking the company’s e-commerce site down for several days. The likelihood of these scenarios is roughly the same, but the web server damage is the far more severe threat because it interrupts the company’s income stream. Therefore, the more severe threat warrants a greater attempt at prevention.

Microsoft 365 provides tools that administrators can use to predict, detect, and respond to security threats. However, a comprehensive risk management plan goes beyond these types of tools and incorporates policies and includes purchasing policies, hiring policies, building policies, and administration policies.

Updating the plan

Risk management is not a one-time event; it must be a continual process to be effective. Security threats continue to evolve at a rapid rate, so the protection against them must evolve as well. At least once a year, the risk management team should repeat the entire assessment process, updating the inventories of all the organization’s information, hardware, and human assets to ensure that no changes have occurred without the company’s knowledge. The team must update the threat severity and likelihood matrix as well. New or updated threats will require new security tools, procedures, and policies to provide protection against them.

In addition to the internal updates of the risk management plan, an organization might want to engage outside contractors to perform a vulnerability assessment, which is an evaluation of the threats in an organization’s security infrastructure. Depending on the size of the organization and the current nature of its possible threats, a vulnerability assessment can be a minor and relatively inexpensive procedure or an elaborate and costly undertaking.

Some of the specific types of vulnerability assessments are as follows:

• Network scan Identifies avenues of possible threats through internal network and Internet connections, including router, firewall, and virtual private network (VPN) configurations

• Wireless network scan Evaluates the organization’s Wi-Fi networks for vulnerabilities, including improper configuration, antenna placement, and rogue access points

• Host scan Identifies vulnerabilities in servers, workstations, and other network hosts, including port and service scans, configuration settings, and update histories

• Application scan Examines web servers and other Internet-accessible servers for software vulnerabilities and configuration issues

• Database scan Identifies database-specific threats in database servers and the databases themselves

Another possible method of assessing security vulnerabilities in an organization’s risk management system is to have a penetration test performed. A penetration test is a procedure in which an outside contractor is engaged to attempt an attack on the company’s systems to ascertain whether the potential vulnerabilities identified in the risk management process are actual vulnerabilities and to assess the organization’s response procedures.

Identity

It’s easy to build a perfectly secure house; just omit all the windows and doors. Your possessions will be safe, but you won’t be able to get at them. In the same way, it would be easy to build a perfectly secure network by establishing a formidable perimeter around the sensitive resources and not letting anyone at all through it. This would be pointless, of course. Workers need access to those sensitive resources, and identities are the basis of that access. In enterprise networking, an identity is a collection of attributes that uniquely describe a security principal, that is, a specific individual and the resources that individual is permitted to access.

For data to be secure, the most fundamental types of protection are ensuring that the individuals accessing the data really are who they claim to be and that the individuals have been granted appropriate levels of access to the data they need. The process of confirming a user’s identity on the network is called authentication, and the process of granting a user access to specific data or services is authorization. Securing the identities of the network’s users is the process of making these procedures as safe and impenetrable as they can be.

The identities of an organization’s users are the prime target for cybercriminals because stealing a user’s name and credentials enables the attacker to access everything that the user knows about the company. News stories regularly report thefts of large blocks of identities from major companies, which endanger not just the companies’ sensitive data but their employees’ personal lives as well. For example, the theft of the names, addresses, and Social Security numbers that are part of any organization’s human resources records leave users open to credit fraud and numerous other criminal intrusions. For the organization, identity theft can be catastrophic in many ways, resulting in data theft, damage, or destruction that can prevent the company from doing business and cost it vast amounts of money.

The attacks that attempt to steal user identities can be extremely simple or incredibly sophisticated. A major security breach for an organization can begin with one intruder calling an unsuspecting user on the phone and claiming to be Jack Somebody from account maintenance in the IT department and talking the employee into disclosing the user’s login name and password. Once the intruder has one user’s credentials, it becomes easier for the intruder to gain others. This sort of lateral movement within the organization’s security infrastructure can be a slow and methodical process that eventually yields access to an identity with high-level access to the network and leads to a major security event. This is why administrators should take pains to protect all the organization’s identities, not just the ones with elevated privileges.

In Microsoft 365, Azure Active Directory (Azure AD) allows administrators to create user identities and performs the authentication and authorization processes, as shown in Figure 3-8. Azure AD is a directory service that is a cloud-based alternative to Active Directory Domain Services (AD DS), which has been the on-premises directory service for Windows networks since 1999. The primary objective in creating Azure AD is the ability to service identities and perform authentications and authorizations for cloud-based resources. This is an essential element of administering Microsoft 365.

An Azure-based Active Directory implementation is necessary for Microsoft 365 because AD DS is limited to providing on-premises security functions. Users must have access to the on-premises network to sign in to their organization’s AD DS domain controllers. The only way a remote user can authenticate to the company network using AD DS is to establish a connection to an on-premises server, such as a virtual private network (VPN) connection. Azure AD is strictly cloud-based and enables users working anywhere and with any device to sign in to the organization’s Microsoft 365 network and gain access to its services. Another advantage of a cloud-based directory service is that administrators can create identities for people outside the organization, such as partners, clients, vendors, or consultants, who need occasional or restricted access to company resources.

Creating an identity in Microsoft 365 is a simple matter of supplying name values in a form like the one from the Azure Active Directory Admin Center shown in Figure 3-9. The Microsoft 365 Admin Center contains a similar form that also enables the creator of the identity to assign product licenses, such as a Microsoft 365 license, to the user. While creating identities is a quick and easy process, securing them can be considerably more complicated.

The traditional means of authenticating a user’s identity is for the individual to supply an account name and a password. In Microsoft 365, administrators can create password policies that compel users to create long and complex passwords and change them frequently. However, passwords are always subject to potential weaknesses that make them an unwieldy authentication mechanism, including the following:

• Users might have difficulty remembering long or complex passwords and write them down in unsecured locations.

• Users might share their passwords with coworkers for the sake of convenience.

• Users with dedicated accounts that have elevated privileges might overuse their administrative passwords for everyday tasks.

• Users might supply the same passwords for multiple services or resources, compounding the damage if a password on one server is compromised.

• Users might be tricked into supplying their passwords by phishing or social engineering attacks.

• Users’ identities might be compromised when their passwords are subjected to replay attacks, in which an intruder retransmits a captured password to gain access to a protected resource.

• Users’ passwords might be compromised by malware that captures keystrokes and transmits them to an intruder.

• Some users can be relentlessly clever in discovering ways to evade the password policies imposed on them.

Because some of the weaknesses of password-based authentication are caused by human failings rather than technological failings, the process of strengthening user passwords is often an educational one. Administrators can devise policies to mitigate some password weaknesses, though urging users to abide by them can be difficult.

For example, a 20-character, randomly generated, administrator-assigned password would be extremely difficult for attackers to compromise, but it might be equally difficult to put down the outright insurrection that could result from the users forced to use them. Because of the complications inherent in the use of passwords, Microsoft 365 supports other types of authentication mechanisms that administrators can use instead of (or along with) passwords.

Windows Hello for Business is a desktop authentication mechanism that can replace passwords with certificate or key pair authentication using a PIN or a biometric credential, such as a fingerprint scan or an infrared facial recognition process. Microsoft Authenticator is a mobile device app that enables users to sign in to a Microsoft account using a combination of authentication mechanisms, including PINs, biometrics, and one-time-passcodes (OTPs).

Documents

As noted earlier in this chapter, virtually all the security mechanisms in Microsoft 365 are ultimately intended to protect the enterprise’s information, and documents are one of the primary containers for that information. The traditional method for securing documents is to apply access control permissions to them. Permissions take the form of access control lists that are stored as attributes of individual files and folders. An access control list (ACL) consists of multiple access control entries (ACEs), each of which specifies a security principal, such as a user or group, and the permissions that grant the principal certain types of access to the file or folder.

Permissions specify who can access documents and what actions users can perform. For example, a user might be able to read a document but not modify it, while another user might not even be able to see that the document exists. Permissions have been around for decades, and they enable users and administrators to restrict access to particular documents, but they must be applied manually and are difficult to manage for a large document collection. Someone also must keep track of which documents contain sensitive information that requires additional protection.

Microsoft 365 therefore includes security mechanisms, such as Azure Information Protection (AIP) and Data Loss Prevention (DLP), which can protect documents in other ways. The process of identifying documents containing sensitive data and securing them consists of the following four steps:

• Discovery The location of documents containing sensitive information, either by automatic detection based on established data patterns or by prompting users to apply classification labels

• Classification The application of labels to documents containing sensitive information that indicate what types of protection should be applied to them

• Protection The implementation of specific security mechanisms to documents based on the classification labels that have been applied to them

• Monitoring The process of tracking document access trends, activities, and events and taking action when necessary

The process of discovering documents containing sensitive information is highly dependent on the nature of the organization, the types of businesses it is engaged in, and the policies or regulations with which it must comply. Tools like Data Loss Prevention have preconfigured sensitive information types that enable the automated discovery of documents that contain common data patterns, such as credit card and Social Security numbers. Also, administrators can create customized sensitive information types that can discover documents that contain specific industry-based keywords and data patterns.

Like a physical label, the sensitivity labels provided by tools like AIP and DLP can warn users that a document contains sensitive information and recommend that certain actions be taken. The labels persist with the documents as they travel to different systems and are opened in other Office applications—even those on other computing platforms. However, AIP and DLP labels can also be configured to apply various types of protection, like those shown in Figure 3-10. The labels can cause documents to be encrypted, both at rest and in transit; limited to use with specific applications; restricted to specific users or devices; or configured to expire and even be deleted after a specified lifespan.

Once the document classification and protection phases are complete, it is still the responsibility of administrators to monitor the reports and alerts that are generated by the security tools. For example, repeated attempts to access or share protected documents by the same user or device can indicate the presence of a security breach, even if the attempts fail. The monitoring process should include remediation as well so that an administrator who notices anomalous behavior can intervene by revoking document access privileges or quarantining files.

Network

The traditional network security model calls for the construction of a perimeter surrounding the enterprise premises; this traditional model has servers, workstations, and users all located inside the perimeter and firewalls protecting them by filtering out unwanted traffic. Remote users could connect to enterprise resources only by establishing a secured connection to a remote access server located in a DMZ on the perimeter network. A Microsoft 365 installation places substantial and potentially vulnerable resources outside the perimeter in the cloud, requiring a revised network security model.

Remote users might still connect to on-premises servers for some functions, but others will connect directly to cloud services. Also, the new emphasis on mobile devices means that users will be accessing enterprise resources from a wider variety of locations, including public locations, such as hotels and coffee shops, over which the company has no control.

The Microsoft 365 deployment process begins with an assessment and possibly a redesign of the network to ensure that Internet bandwidth and proximity to the nearest Microsoft cloud endpoint is optimized. Also, adapting the security model to a network infrastructure that includes cloud services requires a shift in emphasis from perimeter security to endpoint security, in which the focus is placed more on securing the locations of the data and the locations of the users accessing the data than on the network medium connecting them.

While the security perimeter around the existing data center must remain in force, the load on the firewalls might be substantially decreased by the migration to cloud services. In some cases, firewall barriers might have to be weakened deliberately to enable Office 365 traffic to reach the cloud. However, this does not mean that the standard means of protecting the firewalls themselves, such as changing their administrative login names and passwords on a regular basis, can be abandoned.

Endpoint network security means that the protective features built into the Microsoft 365 cloud services take on a more prominent role in the enterprise security strategy. Microsoft 365 administrators do not have control over the network traffic reaching the cloud services, nor can they erect a perimeter around every remote or mobile device that accesses the enterprise services. Therefore, instead of trying to block malicious traffic with firewalls, security comes from mechanisms such as multifactor authentication, Data Loss Prevention, and Cloud App Security.

This does not mean that the networks themselves cease to be vulnerable or that they can be left unprotected. Administrators must be wary of the threats that have always afflicted networks, including unauthorized packet captures, unprotected Wi-Fi networks, and rogue access points. For example, if an enterprise allows both managed and unmanaged devices to access company resources—regardless of the policies they use to control that access—it is still a good idea to keep the managed devices on a separate wireless network from the unmanaged ones. Also, internal Wi-Fi networks must still be protected by appropriate security and encryption protocols, and their administrative passwords and preshared keys must be modified on a regular basis.

Devices

If one of the two main innovations of Microsoft 365 is the use of cloud-based services, the other is the ability of users to access those services using many different types of devices that run on various computing platforms and work at any location that has Internet access. As noted earlier, VPN connections have long enabled remote users to access the company network from home or while traveling, using a laptop or desktop. VPNs use a technique called tunneling to protect the data as it is transmitted over the Internet. In subsequent years, there were a few mobile devices—nearly always supplied to users by the company—that were able to access a remote network, but with limited utility, such as email only. Today, Microsoft 365 enables remote users working with desktops, laptops, tablets, and smartphones to access virtually any enterprise service or resource that they could access using an on-premises workstation. The trick, however, is not just to make this access possible, but to make it secure as well.

Device security in Microsoft 365 therefore must address two relatively new issues:

• Mobile devices that frequently operate outside of the organization’s protective perimeter

• The increasing use of mobile devices that are not selected and owned by the company

Because mobile devices can access any and all sensitive information maintained by the enterprise, it is essential that there be some means to protect that information from the threats to which all mobile devices are subject, including loss, theft, and misuse.

While administrators can still use traditional access-control measures, such as file system permissions, to regulate who is able to work with the organization’s sensitive data, it is the Azure Active Directory and Microsoft Intune services that are primarily responsible for ensuring that the devices used to access that data are safe. Microsoft 365 supports a large number of mobile computing platforms, including the following:

• Windows 10

• Android

• Android enterprise

• iOS

• macOS

The interaction between mobile devices and the Microsoft 365 cloud services is a complex one, as shown in Figure 3-11; however, as you can see in the diagram, Microsoft Intune functions as a clearing house for many of these services and uses Azure AD for authentication and authorization.

Even though the organization might support a BYOD (Bring Your Own Device) policy for its users, it is essential that those devices be subject to some form of enterprise endpoint security. This is the primary function of Microsoft Intune, which is Microsoft 365’s endpoint management tool; administrators use Intune to enroll users’ devices and exercise some degree of management on them. By creating health compliance policies using Intune, enrolled devices can be checked for adherence to those policies before Azure AD authorizes them to access enterprise services and information. This is known as conditional access. Because Azure AD and Intune both operate in the cloud, they can function outside of the enterprise’s premises perimeter, just like the mobile devices, and they can control access to the other Microsoft 365 services from any location.

The process of securing devices begins with their enrollment using Microsoft Intune, at which time an administrator must decide what type of management will be imposed on the device. Mobile Device Management (MDM) grants the organization nearly complete control over the device, requiring the user to comply with all the enterprise policies. MDM even allows an administrator to perform a remote wipe of the entire device if it should be lost or stolen, which ensures that any sensitive data is not compromised further.

MDM is intended primarily for use on company-owned devices; it can be problematic to some users who might not like the idea of granting the organization such comprehensive control over their personal property. For example, MDM policies might require smartphone users to sign on with a password or use another authentication mechanism every time they use their phones—something which users might find to be inconvenient.

The alternative is Mobile Application Management (MAM), which provides administrators with control over specific applications running on a device, but it does not provide control over the entire device itself. For example, a similar policy in MAM might require the users to sign in when using Microsoft Exchange to access their email, but they don’t have to sign in every time they turn on their phones. MAM also enables administrators to wipe company data from the phone, but only the data associated with the managed applications can be wiped.

Cloud App Security is another Microsoft 365 tool for mobile and other devices; Cloud App Security is a cloud access security broker application that scans network resources to detect the cloud applications that users are running, and it detects unauthorized Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) products that might be in use. The object here is to detect “shadow IT”—that is, cloud applications that have not been approved by the IT department and which could be a threat to enterprise network security.

Cloud Discovery is the process by which Cloud App Security examines traffic logs from firewalls and proxy servers and compares the information to Microsoft’s cloud app catalog, which contains more than 16,000 cloud applications. The catalog includes an assessment of each application as a potential threat, and scores are based on more than 70 risk factors.

Once Cloud App Security has compiled a report of the cloud applications being used, administrators can then sanction the applications they want employees to use and unsanction those they do not want them to use. For the sanctioned applications, Cloud App Security supports the use of APIs supplied by the cloud application providers. These APIs enable Cloud App Security to function as an intermediary between cloud applications and the enterprise’s users, as shown in Figure 3-12, by accessing activity logs, user accounts, and data sources. Cloud App Security can then use this information to monitor usage, enforce policies, and detect threats.

On-premises identities

Beginning with the Windows 2000 Server release, enterprise identities were stored in Active Directory, which is an on-premises directory service that is still a part of the Windows 2019 Server product, although it is now called Active Directory Domain Services (AD DS). Installing the AD DS role on a computer running Windows Server enables it to function as a domain controller, which contains an object-oriented database of user identities and other network resources, including groups, computers, and applications. AD DS is a domain-based hierarchical database that uses container and organizational unit objects to separate users and other resources into logical collections, which usually represent the departmental or geographic divisions of the company.

Typically, enterprise networks have multiple domain controllers, which administrators configure to synchronize the contents of their AD DS databases with each other, for fault tolerance and high availability purposes. AD DS uses multiple master replication, which means administrators can create or modify users and other objects on any domain controller, and the changes will be replicated to all of the other domain controllers, as shown in Figure 3-14.

Administrators can create AD DS user objects using graphical tools, such as Active Directory Users and Computers, as shown in Figure 3-15, or command-line tools, such as the New-ADUser cmdlet in Windows PowerShell. The user objects in AD DS are strictly on-premises identities. Domain controllers must be located within the network perimeter and are not directly accessible from the Internet. When users access on-premises resources, their identities are authenticated and authorized by the nearest domain controller, which uses a protocol called Kerberos to perform a complicated ticket-based authentication procedure. Users outside the network perimeter can only perform an AD DS sign in to the network by establishing a VPN connection to a remote access server. This provides users with a presence on the internal network, which enables them to access internal resources.

Cloud identities

Because AD DS can only perform its functions when both the user and the resources to be accessed are located on-premises, it is not a viable solution for cloud-based applications and services. Therefore, Microsoft had to devise an alternative authentication and authorization solution for its cloud-based products, such as Microsoft 365. This solution is Azure Active Directory (Azure AD), a cloud-based directory service alternative (or companion) to AD DS in which administrators create cloud identities.

Microsoft 365 relies on the Azure Active Directory service for its identity management, and all the Microsoft 365 services use Azure AD for authentication and authorization. Microsoft 365 subscribers (as well as Office 365 and Windows Azure subscribers) become Azure AD tenants automatically. When a user accesses an Office 365 application in the cloud, as shown in Figure 3-16, Azure AD is the invisible intermediary that confirms the user’s identity with the authentication mechanisms the Microsoft 365 administrators have selected. In the same way, Azure AD authorizes the user’s access to the application and to the files the user opens in the application.

Unlike AD DS, it is not necessary for administrators to install multiple domain controllers for Azure AD or configure directory replication. An Azure AD tenancy is automatically replicated to multiple data centers in the Microsoft Global Network. Also, unlike AD DS, Azure AD uses a single master replication model. There is only one primary replica of an Azure AD tenant, and all new users and account modifications are written to that primary replica. The changes are then automatically replicated to multiple secondary replicas at different data centers, as shown in Figure 3-17. All incoming read requests are handled by the secondary replicas, using the replica closest to the requesting user, application, or service. Because there are many secondary replicas, the Azure AD service is always available. Because there is only one primary replica, it works differently by using a deterministic failover procedure.

To create users in Azure AD, administrators can use several different tools, including the Microsoft 365 Admin Center and the Azure Active Directory Admin Center. Azure ID’s authentication and authorization are also token-based, but the protocols and procedures that Azure AD uses are different from those that AD DS uses. Instead of Kerberos, Azure AD uses OAuth 2.0 or OpenID Connect.

Hybrid identities

It is important to understand that Azure Active Directory is not intended to be a replacement for Active Directory Domain Services, nor are the two interchangeable. If an organization has internal servers and an on-premises AD DS implementation, they should not expect to be able to migrate their user identities from AD DS to Azure AD and then deprecate their AD DS domain controllers. It is equally important to understand that Microsoft 365 requires Azure AD; it is not possible to use AD DS identities to authenticate and authorize users for Microsoft 365 applications and services. The converse is also true; it is not possible to use Azure AD identities to provide authentication and authorization services for on-premises resources.

It is, however, possible to use Azure AD and AD DS together, creating what are known as hybrid identities. A hybrid identity is a user account that exists in both the Azure AD and AD DS directories with the same set of attributes. The usual scenario for the use of hybrid identities is an organization that has an existing AD DS infrastructure, but which is considering an expansion into the cloud by using Software as a Service (SaaS) products, such as Office 365. The organization might have hundreds or thousands of on-premises identities, but the prospect of having to re-create them in Azure AD and then maintain two identities for each user could be a deciding factor in the organization choosing not to use cloud services.

Hybrid identities are a solution to this problem. Because the assumption is that the AD DS identities already exist, creating hybrid identities is a matter of synchronizing them from AD DS to Azure AD. To do this, administrators must install a tool called Azure AD Connect on the on-premises network, which accesses the AD DS directory on a domain controller and replicates all the user accounts it finds to Azure AD (along with their passwords and other attributes).

Passwords in AD DS are stored as a hash (a one-way mathematical algorithm that cannot be reversed to extract the password), and by default, Azure AD Connect applies another hash algorithm to the AD DS hash. Thus, the password transmitted by Azure AD Connect to the cloud is secured by it being a hash of a hash. The passwords in Azure AD are never stored in plain text, nor are they ever encrypted using a reversible algorithm.

After the initial synchronization, Azure AD Connect continues to detect changes made to the AD DS identities and replicates those changes to the corresponding Azure AD identities in the cloud, as shown in Figure 3-18. Therefore, administrators managing hybrid identities must use the AD DS tools, such as Active Directory Users and Computers, to make changes to the on-premises user accounts. Because the identity replication flows in only one direction—from AD DS to Azure AD—no one should make changes directly to the cloud identities using the Microsoft 365 tools.

Hybrid identities can simplify the identity management process for administrators, but they can also simplify the user experience as well. For administrators who are adding cloud services to an existing on-premises infrastructure, the main objective should be to make user access to the cloud applications as invisible as possible. One way to do this is to implement single sign-on (SSO) so that users can authenticate with their familiar AD DS credentials and receive access to the cloud services without having to sign in again, either at the Azure AD level or in the individual applications. Another option, called seamless single sign-on, enables users connected to the enterprise network to be automatically signed in without any interactive authentication. Seamless sign-on is compatible with the password hash synchronization and pass-through authentication methods, but it is not compatible with the federated authentication method.

During the process of installing Azure AD Connect, an administrator must select the authentication method that Azure AD will use to provide the users with access to cloud resources. There are three options to choose from, as follows:

• Azure AD Password Hash Synchronization The simplest form of the Azure AD Connect authentication methods, which requires no additional infrastructure to implement. Azure AD Connect creates a hash of each user’s AD DS password hash and applies it to the corresponding Azure ID identity. This enables users to access both on-premises and cloud resources using the same password, as shown in Figure 3-19. Azure AD Connect updates the cloud identity passwords every two minutes without interrupting a session in progress when a password change occurs. Because the password hash synchronization model is fully implemented in the cloud, it shares the high availability of the other Microsoft cloud services. To ensure continuous operation, Microsoft recommends the installation of Azure AD Connect on two or more servers as a standby, preferably at different locations.

• Azure AD Pass-Through Authentication Avoids all cloud-based password validation by using a lightweight pass-through authentication agent installed on on-premises servers. (Microsoft recommends three.) When users sign in to Azure AD, their requests are forwarded to the agent, which forwards them in turn (in encrypted form) to a domain controller for validation of the users against their on-premises identities in AD DS, as shown in Figure 3-20. The agents require only outbound access to the Internet and access to an AD DS domain controller, so they cannot be located on a perimeter network. The end result is the same user experience as password hash synchronization, but this method avoids the storage of user passwords in the cloud in any form and enables administrators to enforce on-premises Active Directory security policies, such as disabled or expired accounts, and it allows sign-in hours and complies with contracted security requirements. It is also possible to deploy password hash synchronization in addition to pass-through authentication to function as a backup in the event of an on-premises failure that prevents the agents from functioning.

• Federated Authentication Offloads the authentication process to an external solution that the organization trusts, such as Microsoft Active Directory Federation Services (AD FS). The configuration and management of the authentication process— as well as the user experience—are the responsibility of the federated system; Azure AD is not involved. Depending on the security requirements of the organization, the sign-in process with the federated system might be simpler or more complicated than that of Azure AD. The federated system typically consists of a load-balanced cluster of servers—called a farm—for high availability and fault-tolerance purposes. Because the federation servers require access to both Azure AD and AD DS domain controllers, the servers themselves (or proxy intermediaries) must be located in the DMZ of an on-premises perimeter network, as shown in Figure 3-21. Organizations typically opt for the federated authentication option because they want to (or are compelled to) use an authentication method that Azure AD does not support, such as certificates or smart cards. The additional hardware, software, and administrative infrastructure that the federated authentication method requires can be a significant extra expense; in many cases, organizations that choose this option do so because they have already invested in the infrastructure. It is also possible to deploy password hash synchronization in addition to federated authentication, so that it functions as a backup in the event of an on-premises failure that prevents federation servers or their proxies from functioning.

Password authentication

A password is something you know, and this has been the standard means of authenticating users’ identities for many years. Password authentication costs nothing to implement, and it can be relatively secure. However, there are many possible flaws in the password authentication model. For example, passwords can be forgotten, shared, written down, easily guessed, or overly simple.

To prevent users from creating passwords that provide too little security, there are policies that specify rules for the creation and maintenance of passwords. Operating systems and directory services, such as Azure AD and AD DS, include tools that administrators can use to create and enforce such policies.

In Azure AD, user accounts are subject to the following password policies:

• Characters allowed Specifies the characters that users are permitted to use when creating passwords, including upper- and lowercase alphabetical characters, numbers, blank spaces, and most symbols.

• Password restrictions Specifies that passwords must have from 8 to 256 characters and must contain three of the following four character types: uppercase, lowercase, number, and symbol.

• Passwords expiry duration Specifies that passwords expire in 90 days by default. The value can be modified using the Set-MsolUser PowerShell cmdlet.

• Password expiry notification Specifies that the user will receive a password expiration notification 14 days before the password is set to expire. The value can be modified using the Set-MsolPasswordPolicy PowerShell cmdlet.

• Password expiry Specifies a default value of False, indicating that the password will expire after the Passwords expiry duration interval. The value can be modified using the Set-MsolUser PowerShell cmdlet.

• Password change history Specifies that users cannot reuse the same password when changing passwords.

• Password reset history Specifies that users can reuse the same password when resetting a forgotten password.

• Account lockout Causes users to be locked out of their accounts for one minute after 10 unsuccessful but unique sign-in attempts. Additional unsuccessful attempts result in longer lockout intervals.

In AD DS, administrators can configure password settings using Group Policy. The available settings have slightly different names, but their functions are essentially the same.

These password policies are designed to prevent users from creating passwords that are overly simple for the sake of convenience, but password security is difficult for administrators to enforce. Users can still create passwords that would be easy for attackers to guess by using their children’s names and birthdays, for example. There is also no software setting that can prevent users from writing their passwords down or sharing them with their coworkers.

As threats to network security become ever more severe, administrators have sought for ways to enhance the security of the authentication process. There have been alternative authentication methods available for many years, which could conceivably augment or replace passwords, but until relatively recently, these technologies were too expensive or inconvenient to be practical for the average user base. The increased need for identity protection has brought these authentication technologies to a wider market, however, resulting in lower prices, and the need is increasing constantly. Microsoft 365 includes the ability to enhance the security of the authentication process in a variety of ways.

Multifactor authentication

Multifactor authentication is a procedure in which users prove their identities in two or more ways. Typically, in addition to a password—something you know—they supply a different authentication factor: something you are or something you have.

SOMETHING YOU HAVE

While the something you have in multifactor authentication can be a smart card or some other form of identification, in Microsoft 365, it is usually a cell phone. This is a more practical option because most people today carry cell phones with them, while card readers far less common.

It has already become common for Internet websites to require a secondary authentication factor, usually in the form of a code (called a one-time password or OTP) sent to the user’s cell phone as a call or SMS text. The user supplies the code in the website and authorization is granted. Microsoft 365 supports this method for multifactor authentication of users’ Azure AD identities, among others.

The cell phone-based options for Azure AD Multifactor Authentication (MFA) are as follows:

• SMS Text Of OTP Code To Mobile Phone After the user completes the password authentication, Azure AD sends a text message containing an OTP code to the user’s preconfigured telephone number. The user types the code into the sign-in screen to complete the authentication.

• Automated Voice Call To Mobile Phone After the user completes the password authentication, Azure AD generates an automated voice call to the user’s preconfigured telephone number. The user answers the call and presses the phone’s # key to complete the authentication.

• Notification To Mobile App After the user completes the password authentication, Azure AD sends a notification to the Microsoft Authenticator app on the user’s smartphone. The user taps the Verify button in the app to complete the authentication.

• Verification Code In Mobile App The Microsoft Authenticator app generates a new OATH verification code every 30 seconds. After the user completes the password authentication, the user types the current verification code from the Microsoft Authenticator app into the sign-in screen to complete the authentication.

Of course, cell phones can be lost, stolen, or destroyed, so any authentication method that relies on them is not going to be completely secure, but in combination with a password, they provide a significant barrier against the standard attacker. Multifactor authentication is not required for Microsoft 365, but it is rapidly becoming a de facto standard for network security, largely because many administrators are finding that they have reached the limit of password authentication, as far as users’ tolerance is concerned.

Administrators can enable multifactor authentication for specific users using the Azure Active Directory Admin Center. When the users next sign on, a screen informs them that more information is required. Another screen, shown in Figure 3-22, then enables them to enter a phone number and specify whether the initial contact to a user should be through a code sent to the user’s cell phone or through a mobile app, such as Microsoft Authenticator.

After the initial successful multifactor authentication, another screen appears, as shown in Figure 3-23, on which the users can select from among the cell phone–based authentication options listed earlier and configure a phone number or the Authenticator app.

Identity protection

All identities are a potential source of risk for the entire network, no matter what level of privileges they possess. Once attackers compromise one identity, it becomes relatively easy for them to spread laterally within the enterprise and compromise others. For that reason, administrators should make every effort to protect all identities, not just the ones with administrative privileges.

One of the key innovations of Microsoft 365 is the greater emphasis on proactive threat detection and remediation. Azure AD can provide this type of security for user accounts with a feature called Azure AD Identity Protection. Identity Protection works by evaluating the sign-in activities of individual user accounts and assigning them risk levels that increment when multiple negative events occur. There are two risk levels associated with each identity, as follows:

• Sign-in risk The probability that an unauthorized individual is attempting to authenticate with another person’s identity

• User risk An accumulated probability that a specific identity has been compromised

Azure AD Identity Protection recognizes the following risk events and modifies an identity’s two risk levels based on the order and frequency in which they occur:

• Atypical travel The user signs in from a location that is not typical for the user or that is geographically impossible, based on the user’s other recent sign ins. Azure AD takes into account the travel time between the locations and gradually develops its own profile of the user’s habits, which helps to prevent the occurrence of false positives (that is, conclusions of risk from sign-in patterns that are common for that user).

• Anonymous IP address The user signs in from a browser that suppresses the user’s IP address, such as Tor or a virtual private network (VPN) client. The user signing on might or might not be the owner of the identity, but Azure AD considers the anonymity itself to be suspicious.

• Unfamiliar sign-in properties The user signs in from a client that has unfamiliar properties, such as a new location or an unusual IP address or autonomous system number (ASNs), based on the user’s previous activities. For new identities, there is a period of information gathering that lasts at least five days, during which Azure AD makes no risk assessments using this criterion.

• Malware linked IP address An identity is associated with an IP address that has previously been used to contact a known bot server on the Internet. The system is then assumed to be infected with malware and considered to be a risk.

• Leaked credentials An identity is determined to use credentials that are known to have been compromised. Microsoft gathers information about such credentials from numerous sources, including law enforcement agencies, security consultants, and illicit websites.

When these events occur, Azure AD evaluates them and modifies the behavior of the authentication process according to criteria established by administrators. There are obviously many possible combinations of behaviors that Azure AD might have to take into account when evaluating the risk levels of an identity. For example, if the same risk events occur repeatedly, the risk levels will continue to rise until a drastic reaction might be required, such as blocking all access to the identity.

The basic Azure AD Identity Protection process is illustrated in Figure 3-24.

As an example, when a user attempts to sign in with a simple password from an anonymous IP address, Azure AD determines that it is a risk and assigns it a sign-in risk level of medium. This risk level causes Azure AD to implement a Conditional Access policy that imposes a specific action, such as requiring multifactor authentication during the sign-in process. If the user successfully completes the multifactor authentication, the user risk level remains unchanged.

However, if the user fails to complete the multifactor authentication, Azure AD considers this to be a possible indication that the identity has been compromised and raises the user risk level. The next time the user attempts to sign on, the process might proceed completely normally, with no sign-in risk detected; however, the user risk level associated with the identity persists, and Azure AD might be configured to prompt the user to change the password as a result.

Azure AD Identity Protection is included only with the Azure Active Directory Premium P2 plan, which is supplied with the Microsoft 365 Enterprise P2 edition.

Azure Active Directory

Azure AD is available in three plans, as shown in Table 3-3. All the Microsoft 365 products include either the Premium P1 or Premium P2 plan.

The Azure Active Directory Premium P1 plan supports the following features and services:

• Unlimited directory objects Enables administrators to create cloud identities for an unlimited number of users.

• User and group management Enables administrators to create and manage user and group identities using cloud-based tools, such as the Azure AD admin center and the Microsoft 365 Admin Center.

• Cloud authentication Enables users to sign on to the network using hybrid identities stored in the cloud and with password hash synchronization or pass-through authentication.

• Synchronization with AD DS using Azure AD Connect After installing the Azure AD Connect tool on an AD DS domain controller or on-premises server, on-premises identities can be replicated to the Azure AD directory in the cloud. This creates hybrid identities that enable users to access both cloud-based and on-premises resources with a single sign-on.

• Seamless single sign-on Enables users with hybrid identities that are connected to the on-premises network to sign in with no interactive authentication procedure.

• Support for federated authentication Enables administrators to offload the Azure AD authentication process to a federated service, such as Active Directory Federation Services.

• Multifactor authentication using phone, SMS, or app Enables administrators to require that users supply two or more forms of identification when signing in with an Azure AD identity, such as a password plus a biometric scan or a one-time code sent to the user’s smartphone.

• Support for hybrid user access to cloud and on-premises resources Enables users with hybrid identities to access both cloud-based and on-premises resources after a single Azure AD authentication.

• Self-Service Password Reset Enables users with cloud-based identities to modify their passwords without administrator assistance.

• Device write-back from Azure AD to AD DS identities Enables devices registered in Azure AD and modified cloud identity passwords to be copied to an AD DS container. Ordinarily, Azure AD Connect only synchronizes data from AD DS to Azure AD.

• Application Proxy Enables cloud-based remote users to access internal web applications by forwarding their requests to a connector running on an on-premises server.

• Dynamic groups Enables administrators to create rules specifying the attributes a user account must possess to be automatically added to a group.

• Group naming policies Enables administrators to create policies that specify a format for group names. For example, group names can be required to specify a function, a department, or a geographic location.

• Conditional access Enables administrators to specify conditions that mobile devices must meet before they are granted access to cloud-based resources, such as sign-in risk, client app in use, the state of the mobile device, and the location of the device.

• Microsoft Identity Manager Provides identity and access management, including synchronization of users, groups, and other objects for AD DS and Azure AD, as well as third-party directory services.

• Azure Information Protection Premium P1 Enables users and administrators to classify and label documents based on the sensitivity of the data they contain.

• Security and activity reporting Provides administrators with reports that list potential threats, including risky sign-ins and audit logs that document user activities.

With these features and services, the Azure Active Directory Premium P1 plan enables administrators to manage an organization’s cloud-based resources, as well as identify, predict, detect, and remediate a wide variety of security threats. However, the Azure Active Directory Premium P2 plan supports everything included in the P1 plan and also provides the following additional security features:

• Azure AD Identity Protection Evaluates users’ sign-in activities, quantifies their risk levels, and takes action based on those levels.

• Privileged Identity Management Enables administrators to regulate access to sensitive resources by granting temporary privileges to specific users, requiring additional security measures, and receiving notifications when the resources are accessed. The objective is to prevent users with administrative privileges from using them unnecessarily.

• Cloud App Security A cloud-based service that analyzes traffic logs and proxy scripts to identify and monitor the apps that users are accessing.

• Azure Information Protection Premium P2 Expands on the capabilities of the Premium P1 plan by automating the process of identifying, classifying, and labeling documents.

Azure Information Protection is included in all the Microsoft 365 plans, but it is also available with other Microsoft products in a free version with limited functionality and as a separate subscription in two plans of its own, called Premium P1 and Premium P2. Each subscription level adds features, as shown in Table 3-4, and includes all the features of the lower subscription levels.

Active Directory Domain Services

Active Directory Domain Services (AD DS) is an object-oriented, hierarchical directory service that functions as an internal authentication and authorization provider for Windows networks. Because it is not located in the cloud like Azure AD, the primary source of protection for AD DS is the firewall and other perimeter protection surrounding the on-premises network. AD DS domain controllers are Windows servers that are located inside the network perimeter; they must not be deployed in a DMZ or in any other way that leaves them open to access from the Internet.

Also, unlike Azure AD, an AD DS directory must be designed, deployed, and maintained by the network administrators. The service is provided as a role in the Windows Server operating system, which administrators must add after the installation of the operating system itself. An AD DS directory does not include any of the built-in maintenance and fault tolerance found in Microsoft’s cloud services.

Typically, AD DS domain controllers perform no other function other than acting as DNS servers. For example, it is not considered secure to use domain controllers as application or file servers. To ensure fault tolerance and high availability, administrators must install multiple domain controllers, preferably at different sites. The domain controllers replicate the contents of the directory among each other on a regular basis.

Unlike Azure AD, AD DS is a hierarchical directory service that enables administrators to create a directory that emulates their company’s departmental or geographical infrastructure, as shown in Figure 3-26.

Forests, trees, domains, and organizational units are all types of AD DS objects that contain other objects, such as users, groups, and computers, as shown in Figure 3-27. As with a file system, permissions flow downward through the hierarchy. Permissions granted to a container object are inherited by all the objects in that container and by all subordinate containers beneath it. Administrators can design the AD DS hierarchy however they wish.

In AD DS administration, there is a lot more work left to the network administrator than there is in Azure AD. In Azure AD, one can begin creating users and groups immediately after establishing a tenancy, with no need to install and maintain domain controllers or design an infrastructure. There are also no concerns about physical security with Azure AD, because Microsoft is responsible for its data centers and for maintaining the computers that provide the services. The initial cost outlay for an Azure AD directory is also minimal. AD DS requires the purchase of server computers and the Windows Server operating system, but there are no ongoing subscription fees.

Although AD DS uses an infrastructure that is substantially different from Azure AD, it performs the same basic services by authenticating users and authorizing their access to network resources. However, AD DS does not support many of the advanced security features found in Azure AD. For example, it has no internal support for multifactor authentication, although it is possible to use an external authentication service for some additional authentication factors. AD DS also does not include Azure AD Identity Protection, Conditional Access, and Azure Information Protection.

Because domain controllers are often connected to the same network as workstations and other less sensitive systems, they can be vulnerable to a lateral attack from an intruder who has gained access to another system on the network. As a result, even though the domain controllers themselves might be protected, any of the typical attack vectors to which on-premises computers are susceptible can pose a threat to the AD DS implementation. For example, any computer on the network that is not current in its operating system and application updates or that lacks virus or malware protection can be a target for attack and a launch point for a further invasion of the AD DS directory.

AD DS is also more vulnerable to credential theft than Azure AD because of unsafe use of privileged credentials. Administrators of an on-premises network can sometimes be careless about using their privileged identities to perform everyday tasks, such as browsing the Internet or signing on to computers that are not fully secured. In Azure Active Directory Premium P1, these are practices that can be addressed with the Privileged Identity Management feature, but Microsoft has not integrated the Azure AD security tools into AD DS.

Anticipating performance latency

Can cloud-based services provide the performance levels that the organization is accustomed to achieving with on-premises resources? IT professionals familiar with service issues to which Internet services providers and the Internet itself can be subject might question whether a consistently high level of performance is possible with cloud-based services. The comfortingly consistent performance of an internal cable plant, over which the company has complete control, is a difficult thing to lose. There might be concerns as to whether service outages or periods of increased latency might occur that can affect productivity and damage the company’s reputation with its partners and clients.

When considering any cloud service provider, the potential subscriber should investigate the vendor’s service performance record, both by examining any data they provide and by contacting their other clients. Most providers include a Service Level Agreement (SLA) in their contracts that account for service availability, but potential subscribers should inquire about the possibility of a performance level SLA as well.

An examination of the provider’s hardware infrastructure is recommended as well, to determine where their data centers are located in proximity to the company’s sites. Microsoft has addressed this issue by constructing a global network of data centers and by recommending that Microsoft 365 subscribers perform a detailed examination of their own network infrastructure. This is to ensure that each company location accesses the Microsoft cloud services through the Microsoft Global Network endpoint nearest to their physical location.

Selecting service providers

The process of choosing service providers is, of course, critical to any cloud deployment. One of the first questions to consider is whether to use a single provider for all the services the organization requires or evaluate several providers for individual services. Choosing one provider for everything minimizes the chance of service gaps, but it also creates a single point of failure. The selected provider might also not provide the best price for each of the services needed.

For Microsoft 365 subscribers, of course, there is no choice of providers for the services included in the product, but this does not mean that an organization must use Microsoft for its entire cloud infrastructure. Using multiple providers for various services might enable the company to negotiate the best terms for each one, and it also allows the company to maintain relationships with more than one vendor, so that services can be moved to another provider if the circumstances call for it. However, dealing with multiple cloud service providers requires meticulous planning to ensure that the company receives all the services it needs.

The organization should have a complete network infrastructure design before engaging any providers, and a careful comparison of the contracts for the providers is necessary to make sure that all the services called for in the plan are available and accounted for. When adding a new service to an existing cloud-based infrastructure, administrators should compare the new contracts of prospective providers with all the existing contracts that are in force.

The worst-case scenario, in this instance, would be the late realization that a vital infrastructure component is not being supplied by any of the engaged service providers and that none of the providers can supply it. These service gaps can be both expensive and embarrassing to the people responsible.

Avoiding vendor lock-in

Being locked into a single vendor is one of the concerns of many organizations considering a cloud-based infrastructure. Prices and other contract stipulations can change over time, and it might be necessary to switch providers when multiple vendors provide the same services in the future. To prepare for this eventuality, contracts with cloud service providers should always include an exit strategy and language regarding contract novation, whether early or not.

One particularly important concern should be the issue of data reclamation. A large cloud-based enterprise network can generate enormous amounts of data over the course of several years. In the event of a provider switch, the process of reclaiming that data from one provider’s cloud service and moving it to that of another can be extremely lengthy. The organization’s cloud infrastructure plan should account for this eventuality, as should the contracts with both the old and the new providers.

Evaluating vendor robustness

At the time of this writing, the business of providing cloud networking services is dominated by three very large companies, none of which appears to be in danger of failing anytime soon. However, other smaller providers do exist and might offer tempting terms for their services. When considering smaller providers, prospective subscribers should investigate the state of their businesses thoroughly. Decision-makers should weigh the risk of contracting with a small provider—which might conceivably fail sometime in the future—with the business consequences of such a failure, such as possible network downtime and even data loss.

Comparing cost models

Comparing the financial cost of a cloud-based infrastructure with an on-premises one is difficult because they use entirely different models. An on-premises network requires a large outlay for hardware and deployment expenses, but once that cost has been amortized, the network is the property of the company, and the ongoing expense is reduced substantially. A cloud-based infrastructure requires a much smaller initial outlay, but the subscriber fees can be substantial and persist as long as the company uses the service.

There are other cost factors to consider as well. In the on-premises model, the company must plan for future growth and adjust the entire deployment process to account for resources that might not be needed for years. With a cloud-based infrastructure, the subscriber can contract for what services they need right now and add more (or remove) functionality later, whenever it is necessary.

To anticipate the TCO (total cost of ownership) for a cloud-based versus an on-premises network infrastructure, one recommended practice would be to total all necessary expenditures for each model over a period of two to three years. However, the TCO does not necessarily provide the whole picture. The cloud solution can provide other benefits that are more difficult to quantify financially. For example, cloud-subscribed services can be scaled up or down with immediate effect. Typically, cloud providers can deploy new virtual servers, add resources to existing ones, or even supply entirely new services almost immediately. On an on-premises network, an expansion might require the purchase, installation, and deployment of new hardware, which can take weeks or months. Scalability can be an important factor for a company that experiences significant seasonal fluctuations in business.

Securing company data

Arguably the greatest concern for many IT professionals considering a cloud-based network infrastructure is the risk of their data being lost or compromised. Microsoft—and presumably other reputable cloud service providers—note in their service descriptions the mechanisms they use to protect subscribers’ data, such as replicated storage at multiple data centers. Contracts also routinely include an SLA that specifies a guaranteed uptime percentage (99.9 percent, in the case of Microsoft), which all but ensures the availability of the data. However, while the contract might impose a penalty on the provider if they do not meet the terms of the SLA, they will almost certainly not be financially responsible for any losses the subscriber incurs due to downtime.

There is no way around the fact that data stored in the public cloud does have a greater risk of being compromised than data stored on the subscriber’s on-premises servers. To address this risk, Microsoft 365 includes security tools that, when used properly, can help to mitigate the risk of identities being penetrated and data being accessed by unauthorized individuals. However, the burden of applying this protection and of exposing sensitive data to the risk falls on the subscriber in the first place.

It is up to the network’s administrators to assess the sensitivity of the company’s data, classify the data using an agreed-upon taxonomy of sensitivity levels (as discussed in the “Protecting documents” section, earlier in this chapter), and decide what measures they should use to protect the data at each level. Therefore, sn organization that works with extremely sensitive data might choose to store it on-premises, rather than allow it in the cloud at all.

It should also be up to the subscriber to ensure that all data, whether stored in the cloud or on-premises, is backed up on a regular basis, whether the cloud provider includes this service or not. If backups are also to be stored in the cloud, then the best practice would be to use a different provider for the backups, so that the data is stored on a separate network of data centers.

Locating company data

For organizations that are subject to data storage restrictions imposed by their clients or by government entities, the exact locations of a cloud service provider’s data centers can be significant. The Microsoft Azure network is divided into 54 regions (shown in Figure 3-34) and 18 geographies that enable subscribers to maintain their data in places that can honor any specific residency, sovereignty, compliance, or resiliency requirements they might be compelled to observe. This is not necessarily true of all public cloud providers, however, and potential subscribers subject to such restrictions should require providers to include contract language specifying where their data is to be stored.

Obtaining skilled personnel

Because cloud-based services are a relatively new technology, there are not as many skilled administrators and support people for them as there are for traditional on-premises networking technologies. This can mean an enterprise that has an established on-premises network infrastructure but that is considering the addition of or migration to cloud services, the existing IT staff might lack the expertise needed to adequately support the cloud technologies.

One effective way of addressing this issue without replacing all or part of the IT staff is to train or recruit a core cloud network infrastructure design and planning team first. Then that team can function as mentors for the IT personnel that require a reorientation to cloud methodologies.

Transitioning to the cloud

For traditional on-premises network administrators and support personnel, a transition to cloud-based services can be a major rethink in how they do almost everything, and many organizations are reticent to make the change for that reason. Cloud service providers have recognized this, however, and might provide help for subscribers moving into the cloud for the first time.

Microsoft’s FastTrack program is designed for this exact purpose, providing organizations with a specified number of Microsoft 365 subscribers with a clearly defined path into the cloud and onboarding help, for no additional charge. Microsoft maintains its own FastTrack team, as well as a network of partners that can provide transition assistance by breaking the process down into the following three stages:

• Envisioning Provides the subscriber with information about available resources and identifies business-specific scenarios to aid in the creation of an overall cloud deployment and migration plan catered to the organization’s needs

• Onboarding Realizes the plan created during the Envisioning phase by configuring the cloud services; migrating files, email stores, and web content; and creating users and groups, as shown in Figure 3-35

• Driving value Helps the subscriber to develop efficient administration and maintenance practices and provides ongoing aid to the staff in working with Microsoft 365 technologies and adapting them to the organization’s business model

Not all cloud service providers have a program like this, but some will provide assistance; also, there are third-party consultants who can help an organization deal with issues that arise during the transition to a cloud-based infrastructure. IT professionals who are hesitant to adopt cloud technologies, even after realizing the advantages they provide, have many resources available for assistance.