We’ve transitioned the traditional and custom IT tools and features in Microsoft service-desk into ServiceNow ITSM. This has led to innovation in many areas of our IT help-desk management, including improving accessibility, incident management, IT workflows and processes, service level agreements (SLAs), use of AI/ML, virtual agents, automation, and knowledge across the IT help-desk organization data visualization, monitoring and reporting.

In short, our strategic partnership with ServiceNow is helping us improve the efficacy of our internal IT help-desk environment and for our mutual customers.

Working together to accelerate digital transformation

Our Microsoft Global Helpdesk team supports more than 170,000 employees and partners in more than 150 countries and regions. We deploy this new ITSM environment at enterprise scale, supporting more than 3,000 incoming user requests each day.

We collaborate with ServiceNow as a partner to accelerate our digital IT transformation and continually increase the effectiveness of our IT service management. Our Global IT Helpdesk recognizes potential improvements, provides feedback to ServiceNow, and tests new features. We receive accelerated responses to our ITSM solution requirements while ServiceNow gets valuable, large-scale feedback mechanism to continuously improve their platform.

[Explore how we’re streamlining vendor assessment with ServiceNow VRM at Microsoft. | Discover how we’re instrumenting ServiceNow with Microsoft Azure Monitor. | Unpack how we’re using Microsoft Teams and ServiceNow to enhance end-user support.]

Modernizing the internal support experience

In the past, when our internal support scale, business processes, or other factors demanded functionality that existing platforms and systems couldn’t support, our engineers would develop tools and applications to supply the required functionality. Many ITSM features at Microsoft were developed in this manner. With ServiceNow now providing the core ITSM functionality we need, we are working together to integrate our tools’ functionality into their platform, which provides a unified IT help-desk experience that is scalable with enhanced productivity and accelerated digital IT transformation.

ServiceNow enables Microsoft to integrate its digital environment with ServiceNow ITSM functionality and Microsoft uses out-of-the-box ServiceNow functionality whenever suitable. ServiceNow adds and improves functionality, often based on Microsoft feedback and development, and then Microsoft uses the resulting improved capabilities to replace internally developed tools and processes. This collaborative relationship on ITSM benefits both organizations and our mutual customers.

Collaborating to create rapid innovation

In some cases, Microsoft-developed tools are the starting point for new ServiceNow functionality, such as the recent implementation of ServiceNow ITSM Predictive Intelligence.

We initially built an experimental machine learning-based solution in our environment that automatically routed a limited number of helpdesk incidents in ServiceNow by using machine learning and AI. This reduced the amount of manual triage that our support agents had to perform and helped us learn about incident routing with predictive intelligence and identify innovation opportunities.

We then took those learnings and shared them with ServiceNow to help them make improvements to the ServiceNow ITSM Predictive Intelligence out-of-the-box platform tool. By progressing from our experimental solution to ServiceNow ITSM Predictive Intelligence, we benefitted from the out-of-the-box flexibility and scalability we needed to drive adoption of predictive intelligence within our helpdesk services landscape. We’ll use our work with ServiceNow ITSM Predictive Intelligence throughout this case study to highlight the core steps in our journey toward an improved internal support experience.

Establishing practical goals for modernized support

Predictive intelligence is one example among dozens of ITSM modernization efforts that are ongoing between ServiceNow and Microsoft. Other examples include virtual-agent integration, sentiment analysis of user interaction, anomaly detection, troubleshooting workflows, playbooks, and integrated natural-language processing. Enhancing our helpdesk support agent experience by using ServiceNow ITSM involves three key areas of focus: automation, monitoring, and self-help.

Automation

We’re automating processes, including mundane and time-consuming tasks, such as triaging incidents. Automation gives time back to our helpdesk agents and helps them focus on tasks that are best suited to their skill sets. Feature implementation examples include orchestration, virtual agents, and machine learning.

We’re using ServiceNow Playbooks for step-by-step guidance to resolve service incidents. Playbooks allow our agents to follow guided workflows for common support problems. Many playbooks, such as the password-reset process, include automated steps that reduce the likelihood of human error and decrease mean time to resolution (MTTR).

Monitoring

We use monitoring to derive better context and provide proactive responses to ServiceNow activity. Enhanced monitoring capabilities increase service-desk responsiveness and helpdesk agent productivity. Feature implementation examples include trigger-automated proactive remediation, improved knowledge cataloging, and trend identification.

Microsoft Endpoint Manager supplies mobile-device and application management for our end-user devices, and we’ve worked with ServiceNow to connect Endpoint Manager data and functionality into the ITSM environment. This data and functionality supplies device context, alerts, and performance data to ServiceNow, giving device-related details to support agents directly within a ServiceNow incident.

Self-help functionality

Self-service capabilities help our support incident requestors help themselves, by supplying simplified access to resources that guide them toward remediation. It frees up IT helpdesk agents from performing tasks that end users can do and lowers the total cost of ownership, as support-team resources can focus on more impactful initiatives. Feature implementation examples include natural language understanding, context-based interaction, bot-to-bot interactions, and incident deflection.

For example, the ServiceNow Virtual Agent integrates with Microsoft Teams for bot-to-bot interactions. Bot integration and bot-to-bot handoff enable us to continue using the considerable number of bots already in use across the organization, presenting self-help options for our users that best meet their needs. We have also collaborated with ServiceNow to create integration with knowledge and AI capabilities from Microsoft 365 support. Microsoft 365 service-health information, recommended solutions for Microsoft 365 issues, and incident-related data are available in ServiceNow to both end users and agents.

Examining the modern support experience in context

We have a holistic approach to unifying its internal service-desk platform under ServiceNow. The functionality and health of our Global Helpdesk organization drives the experience for our support agents and the people they assist. To Identify opportunities for improvement, we examined all aspects of our support environment, making observations about tool usage, overall experience of support agents, and potential gaps in the toolset that our support agents use. When thinking about new capabilities, such as AI and automation, we needed to understand how our people work. Why and how we perform certain tasks or processes can lose relevance over time, and a deviation from the original way in which we do something can potentially lead to inefficiencies that we must regularly evaluate and address. We placed these observations into the following categories:

• Comprehensive best practices. We’re encouraging our Global Helpdesk team to be a strategic partner in business, design, and transition of support at Microsoft, rather than simply focusing on tactical ticketing and related metrics. Our internal support experience improvements in ServiceNow ITSM go beyond ticketing processes and require a holistic view of all aspects of the support-agent environment. Additionally, implementing new technologies is only one part of the bigger solution in which it’s critical to verify and keep people accountable for adhering to best practices. We’re transforming our Global Helpdesk operations to provide strategic value and achieve business goals alongside the more tactical elements of service-desk operation, such as incident management and resolution.
• Interaction management. Examining how our helpdesk agents and the people they support use ServiceNow ITSM and its associated functionality to drive interface improvements. It also helps identify new modalities to connect our support agents to the issues that our users are experiencing. Our goals include increasing virtual-agent usage and reducing use of less efficient interaction modalities, such as fielding IT support requests over the phone.
• Incident management. Incident management is the core of ServiceNow ITSM functionality and forms the basis for our largest set of considerations and observations. We examine how we create and manage support incidents, triage and distribute them, and then move them toward the final goal of resolution. In all of this, we assess how Global Helpdesk performs incident management and where it can improve. It’s important to understand the use of data to aid incident resolution, and how to better automate and streamline incident processes and consolidate other elements of service-desk functionality into the incident-management workflow. There are many incident-management factors that we evaluate including identifying incident origin, integrating virtual-agent interactions, increasing contextual data in incidents, automating incident routing, deflection and resolution, and improving incident search functionality.
• Knowledge management. We’re improving how our helpdesk agents and users access knowledge for IT support. Consolidating external knowledge sources into ServiceNow centralizes our knowledge management effort and makes the knowledge they contain available across other service-desk processes, such as incident management. Among the factors we’re focusing on are standardizing knowledge article content, supporting proactive knowledge creation, improving knowledge self-service capabilities, and including related knowledge content for incidents.
• Governance and platform management. The overall management of the ServiceNow ITSM platform and how it interacts with our environment and integrates into outside data sources and tools helps Microsoft use ServiceNow data to improve other business processes. We’re focusing on improving formal business processes and integrating with other processes and technology while aligning with Microsoft’s broader business strategies and standards.

Creating value within the helpdesk support experience

Microsoft and ServiceNow are intentionally and thoughtfully continuing to improve the ServiceNow environment, both from the organizational perspective here at Microsoft and from the product perspective at ServiceNow. For each feature and business need that we evaluate, we examine the feature from all applicable perspectives. Our general feature evaluation and migration process includes:

1. Evaluating business needs for applications and features. For each identified feature, we assess the associated business need. This helps us prioritize feature implementation and understand what we could accomplish based on available resources. ServiceNow Predictive Intelligence, our example in this case study, reduced mean time to resolution (MTTR) for incidents and freed up support-agent resources. These factors both positively influenced support agent efficiency and satisfaction. We’d already been using machine learning-based functionality, so the business need was clear.
2. Determining product roadmaps, organizational goals, and support requirements. In this step, we examine a feature’s practical implementation. Understanding how we need to address a feature or feature gap often depends on product roadmaps and feature development in-flight within ServiceNow. Early access to ServiceNow roadmaps and the ServiceNow Design Partnership Program helps guide our decision making as we determine the evolution of features and how they align with our future vision for digital transformation. If ServiceNow is already developing a specific feature in ITSM space, we don’t worry about integrating or recommending our internally developed tools or functionality. However, we often contribute to the improvement of ServiceNow features based on our internally developed tools, as we did with ServiceNow Predictive Intelligence.
   It can be complex to understand the state of ServiceNow with respect to a specific feature and its requirements. We must examine where we’ve customized ServiceNow ITSM to accommodate an internally developed solution and how we can roll back those changes when we retire the internally developed solution in favor of out-of-the-box functionality.
3. Identifying risks, benefits, and effects of migration. Establishing required resource allocation and determining necessary skill sets for the migration process is critical to understanding how each feature migration might affect our service-desk environment and overall ServiceNow functionality. Specific factors we consider include licensing requirements and quality control checks, both of which greatly influence the speed and order of feature migration. We also assess the effects of retiring legacy/custom tools on the Global Helpdesk and other Microsoft teams. Many tools we use were widely adopted and instrumental to daily operations, so we must consider training and transition processes on a feature-by-feature basis. In some cases, a feature or tool’s addition or removal could cause a shift in business processes, so it’s critical that we understand the potential impact. We do this by examining feature migration in the context of organizational goals, standards, and best practices.
4. Obtaining organizational support. One of the most crucial steps is to garner organizational buy-in. Although Microsoft and ServiceNow are strategic partners, it’s critical to get support from key stakeholders here at Microsoft, including our Global Helpdesk and Microsoft Digital process owners. Communication is critical. When we involve all stakeholders, we ensure that we account for all business and technical considerations.
   Rather than getting approval at a high level for the entire ServiceNow support-improvement project, we instead obtain approval for small pilots that focus on fast delivery and high value. This demonstrates the potential for a feature’s broader adoption at the Global Helpdesk. In our predictive-intelligence example, we started by engaging the Global Helpdesk team that was using the experimental machine learning-based incident-routing tool. The existing experimental tool was only routing some incidents, so we proposed a pilot to route the remaining tickets using ServiceNow ITSM Predictive Intelligence. We worked very closely with our internal support team to ensure that the solution met their needs. The pilot demonstrated the tool’s effectiveness in daily operations and proved the tool’s capabilities in production use. This built confidence and trust in the tool and helped drive broader adoption across the organization.
5. Establishing plans for transition, deallocation, and retirement of legacy tools and systems. We had critical decisions to make about retirement and deallocation of existing tools. Many feature transitions involved identifying how we would move or transform data. Addressing data access and security is a common challenge.
   Additionally, with Predictive Intelligence, our team needs real incidents to train the Predictive Intelligence algorithms. This involves moving production data into a development environment, which has security implications. The feature team must proactively engage our Microsoft security team to provide appropriate information. ServiceNow supplies detailed platform-security documentation, which helps us obtain security-related approval. Also, transition often requires retraining. We must arrange training for users of legacy systems so they can use the new features in ServiceNow and understand how the transition might affect their daily activities and overall service-desk operations.
6. Engaging in feature implementation. We implemented features following specific plans, processes, and best practices that we established. Implementation scope and effort varies depending on the feature, and in the case of Predictive Intelligence, the Microsoft development team began by creating a pilot. This enables the team to confirm that ServiceNow ITSM Predictive Intelligence can achieve the required level of routing accuracy. It also provided a proof of concept that enabled us to quickly find gaps in functionality.
   Starting with a prototype means we then have a functional example that’s up and running quickly so we get early feedback on the out-of-the-box capabilities. We were able to start fast, iterate, and deliver a better solution more quickly. However, we also had to examine and account for scalability within the ServiceNow platform to ensure that the solution would work well when widely adopted.
   Predictive Intelligence went live with a small number of incident-routing destinations, which helped build the confidence of the service-desk team. We then expanded the number of assignment groups as we received positive feedback. The rollout required minimal organizational change management because Predictive Intelligence was automating an existing process and the service-desk team was already using an experimental AI tool for automated routing.
7. Measure progress and review results. We measure all aspects of the feature-implementation progress. Identifying and enabling key metrics and reports helps build confidence and trust in each feature’s effectiveness. As we iterate changes and work through a pilot process for any given feature, we keep stakeholders involved and use our results to contribute to the broader digital transformation. It’s also critical for adoption and is an effective way to illustrate benefits and bring other teams onboard.

Integrating ServiceNow ITSM and Microsoft products

In addition to feature enhancement and growth of ServiceNow functionality, Microsoft and ServiceNow are working together to integrate our products with ServiceNow. This enables us to capitalize on their capabilities and make it easier for our customers at Microsoft to integrate ServiceNow into their environment. For example, device-management capability and reporting data from Microsoft Intune, Microsoft’s mobile device management platform, can integrate directly with ServiceNow. This integration improves contextual data within ServiceNow and extends ServiceNow’s capabilities by using Intune and Microsoft Endpoint Manager functionality on managed devices.

Our Microsoft Global Helpdesk team has observed significant benefits from the continued ServiceNow ITSM feature implementations, and we’re still working with ServiceNow on an extensive list of features that we want to implement. Some of the best benefits we’ve observed include:

• Increased business value. We’ve been able to retire custom solutions and the infrastructure that supports them, reducing total cost of ownership and management effort for legacy solutions. Consolidating our service-desk functionality in ServiceNow ITSM makes licensing and maintenance much more simple and more cost-effective.
• Reduced service-desk management effort. The various automation features we’ve implemented have reduced the effort our IT helpdesk agents exert, particularly with respect to mundane or repetitive tasks. AI and machine-learning capabilities have improved built-in decision making, reduced the potential for human error, and given time back to our helpdesk agents so they can focus on the work that demands their expertise. For example, ServiceNow ITSM Predictive Intelligence is routing incidents with 80 percent accuracy, saving considerable time and effort.
• Improved helpdesk agent experience. Unifying our tools and features within ServiceNow ITSM enabled us to create a more simple, easier-to-navigate toolset for our support agents. They can move between tasks and tools more effectively, which increases overall support responsiveness and makes our service desk more efficient.
• Reduced mean time to resolution. We’re experiencing a continual reduction in incident resolution as we integrate features and modernize the agent support experience. For example, ServiceNow ITSM Predictive Intelligence reduced MTTR by more than 10 percent, on average in our pilot project. Based on these numbers, we’re deploying Predictive Intelligence at a broader scale for Global Helpdesk.

While we’ve successfully migrated many internally developed capabilities into out-of-the-box ServiceNow ITSM features and tools, it is an ongoing process and we’re continuing to learn lessons about the migration process and successfully transforming the IT help-desk environment for greater efficiency and a more productive IT-agent experience. Some key lessons we’ve learned and continue to explore include:

• Start small and expand scope as a feature matures. We typically start feature implementation small with a single team or use-case scenario. We use pilot projects to validate a solution, prove feature completeness, and gather proof of concept to gain support from stakeholders. Each pilot project contributes to a broader improvement to ServiceNow functionality.
• Get buy-in from stakeholders early. Establishing organizational support is critical to the overall success of every feature implementation. We work hard to understand who our stakeholders are within Microsoft and make them aware of how a feature implementation might affect them—and ultimately improve our organization.
• Test scalability and establish monitoring early. Starting small results in many quick wins and rapid feature implementation. However, we must ensure that any capabilities we implement can scale to meet enterprise-level requirements, both in functionality and usability. Tracking metrics and maintaining accurate reporting using ServiceNow’s reporting capabilities provides concrete assessment of feature effectiveness as it increases in usage and scale.
• Don’t accept feature requirements at face value. Specific features are easy to quantify and qualify, but we always consider the bigger picture. We ask what business questions or challenges the requirements are addressing and then ensure our perspective always includes holistic business goals. We don’t simply want a granular implementation of a specific feature.

We’re working on a thorough list of feature integrations that include extensive use of AI and machine learning. This will simplify and strengthen predictive and automation capabilities in ServiceNow. We’re also investigating deeper integration between ServiceNow ITSM and Microsoft products including Microsoft 365, Microsoft Dynamics 365 and Azure.

We are excited that our joint efforts have introduced a rapid iteration of feature capability into the ServiceNow platform and the impact this brings to the ITSM industry.

• Read more about Predictive Intelligence with ServiceNow.
• Explore how we’re streamlining vendor assessment with ServiceNow VRM at Microsoft.
• Discover how we’re instrumenting ServiceNow with Microsoft Azure Monitor.
• Unpack how we’re using Microsoft Teams and ServiceNow to enhance end-user support.

The post Modernizing Microsoft’s internal Help Desk experience with ServiceNow appeared first on Inside Track Blog.

At Microsoft Digital Employee Experience (MDEE), we’re embracing our digital transformation and the culture changes that comes with it. With over 98 percent of our IT infrastructure in the cloud, we’re adopting Microsoft Azure monitoring, patching, backup, and security tools to create a customer-focused self-service management environment centered around Microsoft Azure DevOps and modern engineering principles. As we continue to benefit from the growing feature set of Azure management tools, we’ll deliver a fully automated, self-service management solution that gives us visibility over our entire IT environment.

The result?

Business groups at Microsoft will be able to adapt IT services to best fit their needs.

[Explore shining a light on how Microsoft manages Shadow IT. | Discover enabling a modern support experience at Microsoft. | Unpack creating the digital workplace at Microsoft.]
For a transcript, please view the video on YouTube: https://www.youtube.com/watch?v=C1PEhAT1Cns, select the “More actions” button (three dots icon) below the video, and then select “Show transcript.”

Digital transformation at Microsoft

Our MDEE team is a global IT organization that strives to meet Microsoft business needs. Microsoft Azure is the default platform for our IT infrastructure. We host 98 percent of our IT infrastructure in the cloud. Here are a few details:

• More than 220,000 employees
• 150 countries
• 587 locations
• 1,400 Azure subscriptions
• 1,600 Azure-based applications
• 17,000 Azure infrastructure-as-a-service (IaaS) virtual machines
• 643,000 managed devices

Like most IT organizations, we have our roots in the datacenter. In the past, our traditional hosting services were mostly physical, on-premises environments that consisted of servers, storage, and network devices. Most of the devices were owned and maintained for specific business functions. Technologies were very diverse and needed people with specialized skills to design, deploy, and run them. Our achievements were limited by the time required to plan and implement the infrastructure to support the business.

As technology evolved, we began to move out of the datacenter and into the cloud. Cloud-based infrastructure created new opportunities for us and has transformed the IT infrastructure we manage. We continue to grow and adapt in a constantly changing IT landscape.

Traditional IT technologies, processes, and teams

Our traditional datacenters were managed by a legion of IT pros, who supported the diverse platforms and systems that made up our infrastructure. Physical servers, and later virtual servers, numbered in the tens of thousands, spanning multiple datacenters and comprising a mass of metal and silicon to be managed and maintained. Platform technologies ranged from Windows, SQL Server, BizTalk, and SharePoint farms to third-party solutions such as SAP and other information security-related tool sets. Server virtualization evolved from Hyper-V to System Center Virtual Machine Manager and System Center Orchestrator.

To provide a stable infrastructure, we used structured frameworks, such as IT Infrastructure Library/Managed Object Format (ITIL/MOF). Policies, processes, and procedures in the framework helped to enforce and control security and availability, and to prevent failures. Microsoft product engineering groups that used hosting services had a similar adoption process for their application and service needs, which were based on ITIL/MOF.

This model worked well for traditional IT infrastructure, but things began to change when cloud computing and Microsoft Azure began to influence the IT landscape.

Evolution of the hybrid cloud

As IT infrastructure and services began to move to the cloud, the nature of the cloud and how we treat it changed. We’ve now been hosting IT services in Microsoft Azure for a long time, and as Azure has evolved and grown, so has our engagement with Azure services and the volume of our IT services hosted in Azure.

Early Azure: IT-owned, IaaS, and lift-and-shift

In the early years, Microsoft Azure was IT only. We had full control of cloud development, implementation, and management. We could create and manage solutions in Azure, but it was a siloed service.

The infrastructure consisted primarily of IaaS virtual machines that hosted workloads in the cloud the same way that they hosted workloads in on-premises datacenters.

Efficiency gains were small and infrastructure management still used the same tools—sometimes hosted in the cloud and sometimes hosted on-premises and connected to the cloud. It was very much a lift-and-shift migration from the datacenter to the cloud, and our management processes imitated the on‑premises model in much the same way.

The datacenter remained the focus, but that was changing.

Microsoft Azure evolves: PaaS, co-ownership, and cloud-first

As Microsoft Azure matured and more of our infrastructure and services moved to the cloud, we began to move away from IT‑owned applications and services. The strengths of the Azure self-service and management features meant that a business group could handle many of the duties that we offered as an IT service provider—which meant that they could build solutions that were more agile and responsive to their needs.

Microsoft Azure platform-as-a-service (PaaS) functionality matured, and the focus moved from IaaS-based solutions to PaaS-based solutions. Azure became the default target for IT solutions; datacenter decommissioning began as more solutions moved to or were created in Azure. Monitoring and management was becoming cloud-focused as we pointed more of our System Center Operations Manager (SCOM) and System Center Configuration Manager (SCCM) instances at the cloud. Azure-native management started to mature.

Large-scale Azure: Service line–owned, IT-managed, PaaS-first

PaaS quickly became a focus for developers in our business groups, as they realized the agility and scalability they could achieve with PaaS-based solutions. Those developers shifted to PaaS for applications as we transitioned away from IaaS and virtual machine-based solutions.

With the advent of Microsoft Azure Resource Manager, which permitted a broader level of user control over Microsoft Azure services, we saw service lines begin to take ownership of their solutions, and business groups started to manage their own Azure resources.

The datacenter became an inconvenient necessity for apps that couldn’t move to Microsoft Azure. We still used SCOM and SCCM as the primary monitoring and management tools, but we had moved almost all our instances into IaaS implementations in Azure. Azure-native management became a mature product, and we started to plan and deliver a completely cloud-based management environment.

Microsoft Azure in a DevOps culture: Service line–managed, Internet-first, business-first

We’re continually nurturing a DevOps culture—DevOps has transformed the way that Microsoft Azure solutions are developed and operated. Our Azure solutions offer an end-to-end view for our business groups. They’re agile, dynamic, and data-intensive. Continuous integration and continuous development create a continual state of improvements and feature releases.

The Microsoft Azure solutions that our business groups use are designed to respond to their business needs. We actively seek and use Azure-native tools for control over and insight into IT environments, in Azure first, but also, back to the datacenter where required. We’re a long, long way past managing a stack of metal. The modern workplace is here at Microsoft, and it changes every day.

Realizing digital transformation

In the modern workplace, the developers and IT decision makers in our business groups have an increasingly critical business role. Our business groups need the autonomy to make IT decisions that serve their business needs in the best way possible. With 98 percent of our IT infrastructure in Microsoft Azure, we’re increasingly looking to the agility, scale, and manageability that Azure provides. Using this scale, we solve business needs and provide the framework for a complete IT organization, from infrastructure to development to management.

Managing the modern hybrid cloud

Our modern hybrid cloud is 98 percent Microsoft Azure—and Azure is the primary platform for infrastructure and management tools. Azure is not only the default platform for IT solutions—it is our IT solution.

Just as PC sprawl occurred in the late 1990s and server sprawl did the same thing in the 2000s, cloud sprawl is a growing reality. Implementing new cloud solutions to manage the cloud environment and the remaining on-premises infrastructure is critical for our organization. The new Cloud solutions scope includes the flexibility for our engineers to leverage PaaS, Functions, and Container models to optimize the management of Cloud Environments.

Embracing decentralized IT

Decentralized IT services are a big part of digital transformation. We need a management solution that offers us—and our business groups—what we need to manage our IT environments. We always want to maintain governance over security and compliance of Microsoft as a whole, but we also realize that decentralized IT services are the most suitable model for a cloud-first organization.

By decentralizing services and ownership in Microsoft Azure, we offer our business groups several benefits:

• Greater DevOps flexibility.
• A native cloud experience: subscription owners can use features as soon as they’re available.
• Freedom to choose from marketplace solutions.
• Minimal subscription limit issues.
• Greater control over groups and permissions.
• Greater control over Microsoft Azure provisioning and subscriptions.
• Business group ownership of billing and capacity management.

Our goal in the management of modern hybrid cloud continues to be a solution that transforms IT tasks into self-service native cloud solutions for monitoring, management, backup, and security across our entire environment. With this solution, our business groups and service lines have reliable, standardized management tools, and we can maintain control over and visibility into security and compliance for our entire organization.

The areas where we retain oversight include:

• General IT and operational policy implementation, as approved by the subscription owner. Areas include compliance, operations, and incident management.
• Shared network connectivity over Microsoft Azure ExpressRoute, as needed.
• Visibility into infrastructure inefficiencies and self-service tool development.

Our management solution must be as agile as the solutions we manage, and we provide best practices, standards, and consulting for Microsoft Azure management solutions to ensure that our business groups are getting the most out of the platform.

Supporting digital transformation with Microsoft Azure management tools

Managing the hybrid cloud in Microsoft Azure encompasses a wide range of services and activities. For our business groups to improve, they need to monitor their apps and solutions to recognize issues and opportunities. They need a patching and management solution that keeps systems up to date, manages configuration, and automates common maintenance tasks.

We must protect data with a disaster recovery platform and ensure security and compliance for business groups and the entire company. We use the management tools in Microsoft Azure to enable hybrid cloud management.

Monitoring the hybrid cloud

Monitoring is an essential task for our business groups and their service lines. They need to understand how their apps are performing (or not performing) and have insight into their environment. We’ve used SCOM for monitoring at Microsoft for more than 10 years—and a certain rhythm develops when you use a product for that long.

To ease the transition from SCOM to Microsoft Azure monitoring, we developed transition solutions that use native Azure functionality to recreate certain SCOM functions and views in Microsoft Azure Monitor.

The transition solutions consist primarily of PowerShell scripts and documentation. They give our business groups a familiar environment to work in while they become familiar with Microsoft Azure monitoring.

Our business groups can also start in a standardized environment with our built-in tested security and compliance components. This helps us maintain a centralized standard while allowing for decentralized monitoring. We maintain metrics for critical organizational services, but we leave operational monitoring to each business group.

Our Microsoft Azure monitoring is designed to:

• Create visibility. We’re providing instant access to a foundation set of metrics, alerts, and notifications across core Azure services for all business units. Microsoft Azure Monitoring also covers production and non-production environments, as well as native monitoring support across Microsoft Azure DevOps.
• Provide insight. Business groups and service lines can view rich analytics and diagnostics across applications, as well as compute, storage, and network resources, including anomaly detection and proactive alerting.
• Enable optimization. Monitoring results help our business groups and service lines understand how users are engaging with their applications, identify sticking points, develop cohorts, and optimize the business impact of their solutions.
• Deliver Extensibility. Designed for extensibility to enable support for custom event ingestion, and broader analytics scenarios.

We’ve now retired our SCOM environment, leaving Microsoft Azure monitoring as the default for both cloud and on-premises monitoring now focusing on:

• Automated installation and repair of the Microsoft Monitoring Agent using Microsoft Azure Runbooks.
• Centralized visibility into comprehensive health and performance.
• Fully featured transition solution development to enable complete self-service monitoring in Microsoft Azure.
• Complete transition from SCOM to Microsoft Azure.

Patching, updating, and inventory management

As we’ve done for monitoring, we’re using transition solutions to make it easier for business groups to transition from previously used on-premises tools to Microsoft Azure.

Our patching processes depended on our preexisting solutions as we worked through the transition to Microsoft Azure. SCCM and associated agents provided the bulk of our patching, software distribution, and management process, but we’ve moved to Azure in a phased approach as our Azure subscriptions become ready to transition to Azure for management.

We’ve built transition solutions for our business groups to help them transition from the SCCM platform and other legacy tools to the Microsoft Azure update management patching service. We’re maintaining and modifying these transition solutions as Azure features replaced the on-premises functionality.

From a patching and management perspective, we’re focusing on:

• The transition of inventory management from Configuration Manager to Microsoft Azure, including discovery, tracking, and management of IT assets.
• Transition of our update processes to Microsoft Azure Update Management for business groups.
• Enabling self-service patch management. We’re developing an orchestrated deployment of operating system and application updates with Microsoft Azure, including centralized compliance reporting.
• Creating and updating solutions to support the transition of the above areas, including Resource Manager templates, PowerShell scripts, documentation, and Microsoft Azure Desired State Configuration.

The design for patching and management, as with monitoring, is to provide an Microsoft Azure-based self-service solution for our business groups that gives them control over their patching and management environment while giving us the ability to centrally monitor for compliance and security purposes.

Ensuring recoverable data

With Microsoft Azure as the primary repository for business data, it’s extremely important to have an Azure backup solution with which our business groups and service lines can safeguard, retain, and recover their data.

Our data recovery solutions address the following major areas of concern:

• Recover business data from attacks by malicious software or malicious activity.
• Recover from accidental deletion or data corruption.
• Secure critical business data.
• Maintain compliance standards.
• Provide historical data recovery requirements for legal purposes.

Our Microsoft Azure data footprint is immense. We currently host 1.5 petabytes of raw data in Azure and use almost nine petabytes of storage to back up that data.

We’re using Microsoft Azure Backup as a self-service solution. It gives business groups more control over how they perform their backups and gives them responsibility for backing up their business data—because each business group knows its data better than anyone else.

We’re also using Microsoft Azure Backup for virtual machine-level backup, and we’re backing up some on-premises data to Microsoft Azure using Microsoft Azure Recovery Services vaults. We’ve created a packaged solution for backup management in Azure that consists of scripts and documentation—our business groups can use it to migrate to Azure Backup quickly and efficiently.

As with other areas of enterprise management, we’re evaluating new features for Microsoft Azure Backup that will offer more backup capabilities to our business groups.

Embedding security and compliance

Decentralization gets the greatest scrutiny when it comes to security and compliance. We’re responsible for security and legal compliance for the organization, so our security controls are the most centralized of all the cloud management solutions we implement. However, centralization does not directly affect day-to-day solution management for our business groups and their service lines.

We leveraged a broad set of security and compliance practices and tools that are generally applied across all Microsoft Azure subscriptions. The following imperatives govern the general application of security and compliance measures:

• Microsoft Azure Policy. Using Azure Policy, we establish guardrails in subscriptions that keep our service engineers within governance boundaries automatically. Policy can help control a myriad of settings by default, including limiting the network configurations to safe patterns, controlling the regions and types of Microsoft Azure resources available for use, and ensuring data is stored with encryption enabled.
• Automation gives us a chance to keep pace with the constantly changing cloud environment. DevOps is heavily centered on end-to-end automation, and we need to complement DevOps automation with automated security. Automated security saves significant time and cost for apps that are frequently updated, and we can quickly and consistently configure and deploy security.
• Empower engineering teams. In an environment where change is constant, we want to empower our engineering teams to make meaningful, consistent changes without waiting for a central security team to approve an app. Our engineers need the ability to integrate security into the DevOps workflow. They don’t have to take extra measures to be secure, nor do they need to wait for a central security team to approve an app.
• Maintain continuous assurance. When development and deployment are continuous, everything that goes with them needs to follow suit—including security assurance. The old requirements for sign-offs or compliance checks create tension in the modern engineering environment. We want to define a security state and track drift from that state to maintain a consistent level of security assurance across the entire environment. This helps ensure that builds and deployments that are secure when they’re delivered stay secure from one release iteration to the next and beyond.
• Set up operational hygiene. We need a clear view of our DevOps environment to ensure operational hygiene. In addition to understanding operational risks in the cloud, DevOps operational hygiene in the cloud requires a different perspective. We need to create the ability to see the security state across DevOps stages and establish capabilities to receive security alerts and reminders for important periodic activities.

At MDEE, our goal is a completely cloud-based, self-service management solution that gives our business groups concise control over their environments using Microsoft Azure tools and features. We’ll continue to offer updated Azure-based solutions, transitioning away from on-premises, System Center–based management.

As we continue to transition business groups to cloud-based monitoring, we’re growing our feature set and making our Microsoft Azure-based management even better. We envision a near future where our management systems will be completely cloud based, decentralized, and automated—and our organization continuing to build our business in Azure.

• Explore shining a light on how Microsoft manages Shadow IT.
• Discover enabling a modern support experience at Microsoft.
• Unpack creating the digital workplace at Microsoft.
• Read more about understanding our business with app telemetry in Microsoft Azure.
• Check out instrumenting ServiceNow with Microsoft Azure Monitor.
• See how Microsoft is transforming its own patch management with Azure.

Please share your feedback with us—take our survey and let us know what kind of content is most useful to you.

The post Microsoft moves IT infrastructure management to the cloud with Microsoft Azure appeared first on Inside Track Blog.

Microsoft Digital is transforming the way that we manage devices for Microsoft employees. We’re embracing modern device management principles and practices to provide a frictionless, productive device experience for Microsoft employees and a seamless and effective management environment for the Microsoft Digital teams that manage these devices. We’re using Windows 10, Microsoft Intune, Azure Active Directory (Azure AD), and a wide range of associated features to better manage our devices in an internet-first, cloud-focused environment. The move to modern management has begun our transition to Microsoft Endpoint Manager, the convergence of Intune and System Center Configuration Manager functionality and data into a unified, end-to-end management solution.

Addressing the need for modern management

Microsoft Digital is responsible for managing more than 264,000 Windows 10 devices that Microsoft employees around the world use daily. Historically, our management methods have been based primarily on the network and infrastructure on which these devices reside. The corporate network has been the functional foundation of Microsoft operations for more than 30 years. Our technical past was built on Active Directory Domain Services (AD DS) and the accompanying identity and access management principles that work well within a tightly controlled and regulated on-premises network. With this model, Microsoft Digital has been able to manage devices connected within a protected and insulated digital ecosystem.

However, the ways that our devices are being used have changed significantly over the past 10 years and continue to evolve. The corporate network is no longer the default security perimeter or environment for on-premises computing for many companies, and the cloud is quickly becoming the standard platform for business solutions. At Microsoft, we’ve been continually embracing this new model, engaging in a digital transformation that examines our technology and reimagines it as an enabler of greater business productivity.

As a result, the devices that our employees use are increasingly internet focused and interconnected. Our digital transformation entails removing solutions and services from the corporate network and redeploying them in the cloud on Microsoft Azure, Office 365, and other Microsoft cloud platforms.

Assessing device management at Microsoft

Our Windows devices have been managed by System Center Configuration Manager and AD DS for many years. To be our first and best customer and to support a modern device experience, we’ve started transitioning to Microsoft Endpoint Manager by enabling co-management with Intune and Configuration Manager. Our device management team identified several aspects of the device management experience that needed to be changed to better support our devices and users. Some of the most important aspects included:

• Device deployment effort. Our device deployment strategy has been based largely on operating system (OS) images that are heavily customized and geared to specific device categories. As a result, we managed a large number of OS images. Each of these images required maintenance and updating as our environment and requirements changed, which resulted in Microsoft Digital employees investing significant time and effort to maintain those images.
• Management scope. Image deployment relied primarily on a device connecting to the corporate network and the Configuration Manager and AD DS infrastructure that supported the deployment mechanisms. Devices connected outside the corporate network did not have the same experience or deployment and management capabilities as those connected to the corporate network.
• User experience. All these issues had implications for the user experience. If an employee was connected primarily to the internet and not the corporate network, user experience suffered. Policy application and updates were not applied consistently, and many management and support tools, including remote administration, were not available. We had to implement workarounds for these employees, such as establishing virtual private network (VPN) connections back to the corporate network to facilitate more robust device management. Even with VPN, the internet-first experience was not ideal.

Moving to modern device management

To facilitate a modern device experience for our users and better support our digital transformation, we’ve begun the process of adopting modern device management for all Windows 10 devices at Microsoft. Modern device management focuses on an internet-first device connection, an agile, flexible management and deployment model, and a scalable, cloud-based infrastructure to support the mechanisms that drive device management.

Establishing internet and cloud focus

Our modern device management approach begins with and on the internet. The internet offers the most universal and widely available network for our clients. Our modern management methods are built with internet connectivity as the default, which means using internet-based management tools and methods. To enable this, we used Intune and Azure AD to create a cloud-based infrastructure that supports internet-first devices and offers a universally accessible infrastructure model.

Moving from traditional to modern with co-management

The move to modern management necessitates migrating from our traditional methods of device management rooted in Configuration Manager and AD DS. To enable a smooth transition, we decided to adopt a co-management model that enables side-by-side functionality of both traditional and modern infrastructure. This model was critical to ensuring a smooth transition and it enabled us to take a more gradual, phased approach to adopting modern management. Some advantages of the co-management model include:

• Conditional access with device compliance.
• Intune-based remote actions such as restart, remote control, and factory reset.
• Centralized visibility of device health.
• The ability to link users, devices, and apps with Azure AD.
• Modern provisioning with Windows Autopilot.

Adopting a phased approach

We developed a phased approach to moving to modern management. This approach allowed us to adequately test and incorporate modern methods. It also enabled us to choose a transition pace that best suited our business. We outlined three primary phases:

• Phase one: Establishing the foundation for modern management
• Phase two: Simplifying device onboarding and configuration
• Phase three: Moving from co-management to modern management

In each phase, we implemented one of the primary building blocks that would lead us to a fully modern, internet-first, cloud-based device management environment that supported our digital transformation and created the optimal device experience for our employees.

Phase one: Establishing the foundation for modern management

We began by establishing the core of our modern management infrastructure. We determined how it would function and how we would support the transition to modern management from our traditional model. A significant portion of the overall effort was invested in phase one, which established the basis for our entire modern management environment going forward. Our primary tasks during phase one included:

• Configuring Azure Active Directory. Azure AD provides the identity and access functionality that Intune and the other cloud-based components of our modern management model, including Office 365, Dynamics 365, and many other Microsoft cloud offerings.
• Deploying and configuring Microsoft Intune. Intune provides the mechanisms to manage configuration, ensure compliance, and support the user experience. Two Intune components were considered critical to modern management:
  • Policy-based configuration management
  • Application control
• Establishing co-management between Intune and Configuration Manager. We configured Configuration Manager and Intune to support co-management, enabling both platforms to run in parallel and configuring support for Intune and Configuration Manager on every Windows 10 device. We also deployed Cloud Management Gateway to enable connectivity for Configuration Manager clients back to our on-premises Configuration Manager infrastructure without the need for a VPN connection.
• Translating Group Policy to mobile device management (MDM) policy. Policy-based configuration is the primary method for ensuring that devices have the appropriate settings to help keep the enterprise secure and enable productivity-enhancement features. We started with a blank slate, electing to forgo a lift-and-shift approach to migrating Group Policy settings into MDM policy. Instead, we evaluated which settings were needed for our devices within an internet-first context and built our MDM policy configuration from there, using Group Policy settings as a reference. This approach allowed us to ensure a complete and focused approach while avoiding bringing over any preexisting issues that might have resided in the Group Policy environment.
• Configuring Windows Update for Business. Windows Update for Business was configured as the default for operating system and application updates for our modern-managed devices.
• Configuring Windows Defender and Microsoft Defender Advanced Threat Protection (ATP). We configured Windows Defender and Microsoft Defender ATP to protect our devices, send compliance data to Intune Conditional Access, and provide event data to our security teams. This was a critical step, considering the internet-first nature of our devices and the removal of the closed corporate network structure.
• Establishing dynamic device and user targeting for MDM policy. Dynamic device and user targeting enabled us to provide a more flexible and resilient environment for MDM policy application. It allowed us to start with a smaller standard set of policy settings and then roll out more specific and customized settings to users and devices as required. It also enables us to flexibly apply policies to devices if the devices move into different policy scopes.

Phase two: Simplifying device onboarding and configuration

Our process for device onboarding to modern management is relatively simple. As new devices are purchased and brought into the environment, they are deployed and managed by using the modern management model. This is our approach for the entire device-rollout process; it enables us to gradually onboard devices in a relatively controlled manner and avoid the extra effort required to create in-place migration paths for existing devices. We anticipate that this strategy will result in a complete transition to modern management within three years, according to our device purchase and refresh policies.

Simplifying with Windows Autopilot

We’re using Windows Autopilot as the vehicle for simplifying the user experience and ensuring better corporate asset management. Autopilot allows us to greatly simplify operating system deployment for our users and the Microsoft Digital employees who support the process. Autopilot provides several critical enablers to the deployment process, including:

• Automatically join devices to Azure Active Directory.
• Auto-enroll devices into Intune.
• Restrict Administrator account creation.
• Create and auto-assign devices to configuration groups based on a device’s profile.
• Simplify the out-of-box experience (OOBE) and reduce user involvement in the deployment process.

These capabilities allow us to create a simplified user experience and greatly reduce the time required for Microsoft Digital support staff to configure and deploy images to devices.

Phase three: Moving from co-management to modern management

The final phase in our transition to modern management is ongoing. With our current trajectory, we estimate that 99 percent of our devices will be managed under the fully modern model within three years. We’re working within the co-management model and moving toward a fully modern-managed environment. Our next steps include:

• Decommissioning non-modern infrastructure for Windows 10 management when Endpoint Manager and our business are ready for transition.
• Transitioning clients from AD DS to Azure AD and moving to a 100-percent internet-first model for client connectivity.

We’re still on the road to modern device management, but we’ve learned several lessons along the way. These learning experiences have helped us to better enable modern management now and prepare for the future at Microsoft. Some of the most important lessons include:

• Build for the cloud and start fresh. We found that the extra time required to start fresh in areas like policies and deployment planning was well worth the investment. A fresh start allowed us to plan for exactly what our users and business need, rather than trying to restructure an old model to fit a new reality.
• Go at the speed of your business. The transition to modern device management is not a one-click process. It has wide-ranging implications for an organization, and it needs to be approached intentionally and gradually. We found that large-scale, bulk migration simply didn’t provide enough benefit in relation to the effort and planning required to implement it.

Conclusion

Our transition to modern device management will continue over the next few years as we onboard devices and refine our Microsoft Endpoint Manager platform and methods. Microsoft Endpoint Manager gives Microsoft Digital a platform that enables simplified and efficient management and configuration for our devices in an environment that supports and drives our digital transformation. Our planned refinements to modern management will improve the user experience, reduce the time it takes to get reliable, fully functioning devices into our users’ hands, and create cost savings and greater efficiencies in device management for Microsoft Digital.

• Verifying device health at Microsoft with Zero Trust.
• Explore improving security by protecting elevated-privilege accounts at Microsoft.
• Unpack evolving the device experience at Microsoft.
• Keeping Windows 10 devices up to date with Microsoft Intune and Windows Update for Business.
• Migrating mobile device management to Intune in the Azure portal.

Want more information? Email us and include a link to this story and we’ll get back to you.

Please share your feedback with us—take our survey and let us know what kind of content is most useful to you.

The post Managing Windows 10 devices with Microsoft Intune appeared first on Inside Track Blog.

An ever-evolving digital landscape is forcing organizations to adapt and expand to stay ahead of innovative and complex security risks. Increasingly sophisticated and targeted threats, including phishing campaigns and malware attacks, attempt to harvest credentials or exploit hardware vulnerabilities that allow movement to other parts of the network, where they can do more damage or gain access to unprotected information.

We on the Microsoft Digital Employee Experience (MDEE) team, like many IT organizations, used to employ a traditional IT approach to securing the enterprise. We now know that effective security calls for a defense-in-depth approach that requires us to look at the whole environment—and everyone that accesses it—to implement policies and standards that better address risks.

To dramatically limit our attack surface and protect our assets, we developed and implemented our own defense-in-depth approach. This includes new company standards, telemetry, monitoring, tools, and processes to protect administrators and other elevated-privilege accounts.

In an environment where there are too many administrators, or elevated-privilege accounts, there is an increased risk of compromise. When elevated access is persistent or elevated-privilege accounts use the same credentials to access multiple resources, a compromised account can become a major breach.

This blog post highlights the steps we are taking at Microsoft to protect our environment and administrators, including new programs, tools, and considerations, and the challenges we faced. We will provide some details about the new “Protect the Administrators” program that is positively impacting the Microsoft ecosystem. This program takes security to the next level across the entire enterprise, ultimately changing our digital-landscape security approach.

[Learn how we’re protecting high-risk environments with secure admin workstations. Read about implementing a Zero Trust security model at Microsoft. Learn more about how we manage Privileged Access Workstations.]

Understanding defense-in-depth protection

Securing all environments within your organization is a great first step in protecting your company. But there’s no silver-bullet solution that will magically counter all threats. At Microsoft, information protection rests on a defense-in-depth approach built on device health, identity management, and data and telemetry—a concept illustrated by the three-legged security stool, in the graphic below. Getting security right is a balancing act. For a security solution to be effective, it must address all three aspects of risk mitigation on a base of risk management and assurance—or the stool topples over and information protection is at risk.

Risk-based approach

Though we would like to be able to fix everything at once, that simply isn’t feasible. We created a risk-based approach to help us prioritize every major initiative. We used a holistic strategy that evaluated all environments, administrative roles, and access points to help us define our most critical roles and resources within the Microsoft ecosystem. Once defined, we could identify the key initiatives that would help protect the areas that represent the highest levels of risk.

As illustrated in the graphic below, the access-level roles that pose a higher risk should have fewer accounts—helping reduce the impact to the organization and control entry.

The next sections focus primarily on protecting elevated user accounts and the “Protect the Administrators” program. We’ll also discuss key security initiatives that are relevant to other engineering organizations across Microsoft.

Implementing the Protect the Administrators program

After doing a deeper analysis of our environments, roles, and access points, we developed a multifaceted approach to protecting our administrators and other elevated-privilege accounts. Key solutions include:

• Working to ensure that our standards and processes are current, and that the enterprise is compliant with them.
• Creating a targeted reduction campaign to scale down the number of individuals with elevated-privilege accounts.
• Auditing elevated-privilege accounts and role management to help ensure that only employees who need elevated access retain elevated-access privileges.
• Creating a High Value Asset (HVA)—an isolated, high-risk environment—to host a secure infrastructure and help reduce the attack surface.
• Providing secure devices to administrators. Secure admin workstations (SAWs) provide a “secure keyboard” in a locked-down environment that helps curb credential-theft and credential-reuse scenarios.
• Reporting metrics and data that help us share our story with corporate leadership as well as getting buy-in from administrators and other users who have elevated-privilege accounts across the company.

Defining your corporate landscape

In the past, equipment was primarily on-premises, and it was assumed to be easier to keep development, test, and production environments separate, secure, and well-isolated without a lot of crossover. Users often had access to more than one of these environments but used a persistent identity—a unique combination of username and password—to log into all three. After all, it’s easier to remember login information for a persistent identity than it is to create separate identities for each environment. But because we had strict network boundaries, this persistent identity wasn’t a source of concern.

Today, that’s not the case. The advent of the cloud has dissolved the classic network edge. The use of on-premises datacenters, cloud datacenters, and hybrid solutions are common in nearly every company. Using one persistent identity across all environments can increase the attack surface exposed to adversaries. If compromised, it can yield access to all company environments. That’s what makes identity today’s true new perimeter.

At Microsoft, we reviewed our ecosystem to analyze whether we could keep production and non-production environments separate. We used our Red Team/penetration (PEN) testers to help us validate our holistic approach to security, and they provided great guidance on how to further establish a secure ecosystem.

The graphic below illustrates the Microsoft ecosystem, past and present. We have three major types of environments in our ecosystem today: our Microsoft and Office 365 tenants, Microsoft Azure subscriptions, and on-premises datacenters. We now treat them all like a production environment with no division between production and non-production (development and test) environments.

Refining roles to reduce attack surfaces

Prior to embarking on the “Protect the Administrators” program, we felt it was necessary to evaluate every role with elevated privileges to determine their level of access and capability within our landscape. Part of the process was to identify tooling that would also protect company security (identity, security, device, and non-persistent access).

Our goal was to provide administrators the means to perform their necessary duties in support of the technical operations of Microsoft with the necessary security tooling, processes, and access capabilities—but with the lowest level of access possible.

The top security threats that every organization faces stem from too many employees having too much persistent access. Every organization’s goal should be to dramatically limit their attack surface and reduce the amount of “traversing” (lateral movement across resources) a breach will allow, should a credential be compromised. This is done by limiting elevated-privilege accounts to employees whose roles require access and by ensuring that the access granted is commensurate with each role. This is known as “least-privileged access.” The first step in reaching this goal is understanding and redefining the roles in your company that require elevated privileges.

Defining roles

We started with basic definitions. An information-worker account does not allow elevated privileges, is connected to the corporate network, and has access to productivity tools that let the user do things like log into SharePoint, use applications like Microsoft Excel and Word, read and send email, and browse the web.

We defined an administrator as a person who is responsible for the development, build, configuration, maintenance, support, and reliable operations of applications, networks, systems, and/or environments (cloud or on-premises datacenters). In general terms, an administrator account is one of the elevated-privilege accounts that has more access than an information worker’s account.

Using role-based controls to establish elevated-privilege roles

We used a role-based access control (RBAC) model to establish which specific elevated-privilege roles were needed to perform the duties required within each line-of-business application in support of Microsoft operations. From there, we deduced a minimum number of accounts needed for each RBAC role and started the process of eliminating the excess accounts. Using the RBAC model, we went back and identified a variety of roles requiring elevated privileges in each environment.

For the Microsoft Azure environments, we used RBAC, built on Microsoft Azure Resource Manager, to manage who has access to Azure resources and to define what they can do with those resources and what areas they have access to. Using RBAC, you can segregate duties within your team and grant to users only the amount of access that they need to perform their jobs. Instead of giving everybody unrestricted permissions in our Azure subscription or resources, we allow only certain actions at a particular scope.

Performing role attestation

We explored role attestation for administrators who moved laterally within the company to make sure their elevated privileges didn’t move with them into the new roles. Limited checks and balances were in place to ensure that the right privileges were applied or removed when someone’s role changed. We fixed this immediately through a quarterly attestation process that required the individual, the manager, and the role owner to approve continued access to the role.

Implementing least-privileged access

We identified those roles that absolutely required elevated access, but not all elevated-privilege accounts are created equal. Limiting the attack surface visible to potential aggressors depends not only on reducing the number of elevated-privilege accounts. It also relies on only providing elevated-privilege accounts with the least-privileged access needed to get their respective jobs done.

For example, consider the idea of crown jewels kept in the royal family’s castle. There are many roles within the operations of the castle, such as the king, the queen, the cook, the cleaning staff, and the royal guard. Not everyone can or should have access everywhere. The king and queen hold the only keys to the crown jewels. The cook needs access only to the kitchen, the larder, and the dining room. The cleaning staff needs limited access everywhere, but only to clean, and the royal guard needs access to areas where the king and queen are. No one other than the king and queen, however, needs access to the crown jewels. This system of restricted access provides two benefits:

• Only those who absolutely require access to a castle area have keys, and only to perform their assigned jobs, nothing more. If the cook tries to access the crown jewels, security alarms notify the royal guard, along with the king and queen.
• Only two people, the king and queen, have access to the crown jewels. Should anything happen to the crown jewels, a targeted evaluation of those two people takes place and doesn’t require involvement of the cook, the cleaning staff, or the royal guard because they don’t have access.

This is the concept of least-privileged access: We only allow you access to a specific role to perform a specific activity within a specific amount of time from a secure device while logged in from a secure identity.

Creating a secure high-risk environment

We can’t truly secure our devices without having a highly secure datacenter to build and house our infrastructure. We used HVA to implement a multitiered and highly secure high-risk environment (HRE) for isolated hosting. We treated our HRE as a private cloud that lives inside a secure datacenter and is isolated from dependencies on external systems, teams, and services. Our secure tools and services are built within the HRE.

Traditional corporate networks were typically walled only at the external perimeters. Once an attacker gained access, it was easier for a breach to move across systems and environments. Production servers often reside on the same segments or on the same levels of access as clients, so you inherently gain access to servers and systems. If you start building some of your systems but you’re still dependent on older tools and services that run in your production environment, it’s hard to break those dependencies. Each one increases your risk of compromise.

It’s important to remember that security awareness requires ongoing hygiene. New tools, resources, portals, and functionality are constantly coming online or being updated. For example, certain web browsers sometimes release updates weekly. We must continually review and approve the new releases, and then repackage and deploy the replacement to approved locations. Many companies don’t have a thorough application-review process, which increases their attack surface due to poor hygiene (for example, multiple versions, third-party and malware-infested application challenges, unrestricted URL access, and lack of awareness).

The initial challenge we faced was discovering all the applications and tools that administrators were using so we could review, certify, package, and sign them as approved applications for use in the HRE and on SAWs. We also needed to implement a thorough application-review process, specific to the applications in the HRE.

Our HRE was built as a trust-nothing environment. It’s isolated from other less-secure systems within the company and can only be accessed from a SAW—making it harder for adversaries to move laterally through the network looking for the weakest link. We use a combination of automation, identity isolation, and traditional firewall isolation techniques to maintain boundaries between servers, services, and the customers who use them. Admin identities are distinct from standard corporate identities and subject to more restrictive credential- and lifecycle-management practices. Admin access is scoped according to the principle of least privilege, with separate admin identities for each service. This isolation limits the scope that any one account could compromise. Additionally, every setting and configuration in the HRE must be explicitly reviewed and defined. The HRE provides a highly secure foundation that allows us to build protected solutions, services, and systems for our administrators.

Secure devices

Secure admin workstations (SAWs) are limited-use client machines that substantially reduce the risk of compromise. They are an important part of our layered, defense-in-depth approach to security. A SAW doesn’t grant rights to any actual resources—it provides a “secure keyboard” in which an administrator can connect to a secure server, which itself connects to the HRE.

A SAW is an administrative-and-productivity-device-in-one, designed and built by Microsoft for one of our most critical resources—our administrators. Each administrator has a single device, a SAW, where they have a hosted virtual machine (VM) to perform their administrative duties and a corporate VM for productivity work like email, Microsoft Office products, and web browsing.

When working, administrators must keep secure devices with them, but they are responsible for them at all times. This requirement mandated that the secure device be portable. As a result, we developed a laptop that’s a securely controlled and provisioned workstation. It’s designed for managing valuable production systems and performing daily activities like email, document editing, and development work. The administrative partition in the SAW curbs credential-theft and credential-reuse scenarios by locking down the environment. The productivity partition is a VM with access like any other corporate device.

The SAW host is a restricted environment:

• It allows only signed or approved applications to run.
• The user doesn’t have local administrative privileges on the device.
• By design, the user can browse only a restricted set of web destinations.
• All automatic updates from external parties and third-party add-ons or plug-ins are disabled.

Again, the SAW controls are only as good as the environment that holds them, which means that the SAW isn’t possible without the HRE. Maintaining adherence to SAW and HRE controls requires an ongoing operational investment, similar to any Infrastructure as a Service (IaaS). Our engineers code-review and code-sign all applications, scripts, tools, and any other software that operates or runs on top of the SAW. The administrator user has no ability to download new scripts, coding modules, or software outside of a formal software distribution system. Anything added to the SAW gets reviewed before it’s allowed on the device.

As we onboard an internal team onto SAW, we work with them to ensure that their services and endpoints are accessible using a SAW device. We also help them integrate their processes with SAW services.

Provisioning the administrator

Once a team has adopted the new company standard of requiring administrators to use a SAW, we deploy the Microsoft Azure-based Conditional Access (CA) policy. As part of CA policy enforcement, administrators can’t use their elevated privileges without a SAW. Between the time that an administrator places an order and receives the new SAW, we provide temporary access to a SAW device so they can still get their work done.

We ensure security at every step within our supply chain. That includes using a dedicated manufacturing line exclusive to SAWs, ensuring chain of custody from manufacturing to end-user validation. Since SAWs are built and configured for the specific user rather than pulling from existing inventory, the process is much different from how we provision standard corporate devices. The additional security controls in the SAW supply chain add complexity and can make scaling a challenge from the global-procurement perspective.

Supporting the administrator

SAWs come with dedicated, security-aware support services from our Secure Admin Services (SAS) team. The SAS team is responsible for the HRE and the critical SAW devices—providing around-the-clock role-service support to administrators.

The SAS team owns and supports a service portal that facilitates SAW ordering and fulfillment, role management for approved users, application and URL hosting, SAW assignment, and SAW reassignment. They’re also available in a development operations (DevOps) model to assist the teams that are adopting SAWs.

As different organizations within Microsoft choose to adopt SAWs, the SAS team works to ensure they understand what they are signing up for. The team provides an overview of their support and service structure and the HRE/SAW solution architecture, as illustrated in the graphic below.

Today, the SAS team provides support service to more than 40,000 administrators across the company. We have more work to do as we enforce SAW usage across all teams in the company and stretch into different roles and responsibilities.

Password vaulting

The password-vaulting service allows passwords to be securely encrypted and stored for future retrieval. This eliminates the need for administrators to remember passwords, which has often resulted in passwords being written down, shared, and compromised.

SAS Password Vaulting is composed of two internal, custom services currently offered through our SAS team:

• A custom solution to manage domain-based service accounts and shared password lists.
• A local administrator password solution (LAPS) to manage server-local administrator and integrated Lights-Out (iLO) device accounts.

Password management is further enhanced by the service’s capability to automatically generate and roll complex random passwords. This ensures that privileged accounts have high-strength passwords that are changed regularly and reduces the risk of credential theft.

Administrative policies

We’ve put administrative policies in place for privileged-account management. They’re designed to protect the enterprise from risks associated with elevated administrative rights. Microsoft Digital reduces attack vectors with an assortment of security services, including SAS and Identity and Access Management, that enhance the security posture of the business. Especially important is the implementation of usage metrics for threat and vulnerability management. When a threat or vulnerability is detected, we work with our Cyber Defense Operations Center (CDOC) team. Using a variety of monitoring systems through data and telemetry measures, we ensure that compliance and enforcement teams are notified immediately. Their engagement is key to keeping the ecosystem secure.

Just-in-time entitlement system

Least-privileged access paired with a just-in-time (JIT) entitlement system provides the least amount of access to administrators for the shortest period of time. A JIT entitlement system allows users to elevate their entitlements for limited periods of time to complete elevated-privilege and administrative duties. The elevated privileges normally last between four and eight hours.

JIT allows removal of users’ persistent administrative access (via Active Directory Security Groups) and replaces those entitlements with the ability to elevate into roles on-demand and just-in-time.e used proper RBAC approaches with an emphasis on providing access only to what is absolutely required. We also implemented access controls to remove excess access (for example, Global Administrator or Domain Administrator privileges).

An example of how JIT is part of our overarching defense-in-depth strategy is a scenario in which an administrator’s smartcard and PIN are stolen. Even with the physical card and the PIN, an attacker would have to successfully navigate a JIT workflow process before the account would have any access rights.

In the three years this project has been going on, we have learned that an ongoing commitment and investment are critical to providing defense-in-depth protection in an ever-evolving work environment. We have learned a few things that could help other companies as they decide to better protect their administrators and, thus, their company assets:

• Securing all environments. We needed to evolve the way we looked at our environments. Through evolving company strategy and our Red Team/PEN testing, it has been proven numerous times that successful system attacks take advantage of weak controls or bad hygiene in a development environment to access and cause havoc in production.
• Influencing, rather than forcing, cultural change. Microsoft employees have historically had the flexibility and freedom to do amazing things with the products and technology they had on hand. Efforts to impose any structure, rigor, or limitation on that freedom can be challenging. Taking people’s flexibility away from them, even in the name of security, can generate friction. Inherently, employees want to do the right thing when it comes to security and will adopt new and better processes and tools as long as they understand the need for them. Full support of the leadership team is critical in persuading users to change how they think about security. It was important that we developed compelling narratives for areas of change, and had the data and metrics to reinforce our messaging.
• Scaling SAW procurement. We secure every aspect of the end-to-end supply chain for SAWs. This level of diligence does result in more oversight and overhead. While there might be some traction around the concept of providing SAWs to all employees who have elevated-access roles, it would still be very challenging for us to scale to that level of demand. From a global perspective, it is also challenging to ensure the required chain of custody to get SAWs into the hands of administrators in more remote countries and regions. To help us overcome the challenges of scale, we used a phased approach to roll out the Admin SAW policy and provision SAWs.
• Providing a performant SAW experience for the global workforce. We aim to provide a performant experience for all users, regardless of their location. We have users around the world, in most major countries and regions. Supporting our global workforce has required us to think through and deal with some interesting issues regarding the geo-distribution of services and resources. For instance, locations like China and some places in Europe are challenging because of connectivity requirements and performance limitations. Enforcing SAW in a global company has meant dealing with these issues so that an administrator, no matter where they are located, can effectively complete necessary work.

What’s next

As we stated before, there are no silver-bullet solutions when it comes to security. As part of our defense-in-depth approach to an ever-evolving threat landscape, there will always be new initiatives to drive.

Recently, we started exploring how to separate our administrators from our developers and using a different security approach for the developer roles. In general, developers require more flexibility than administrators.

There also continue to be many other security initiatives around device health, identity and access management, data loss protection, and corporate networking. We’re also working on the continued maturity of our compliance and governance policies and procedures.

Getting started

While it has taken us years to develop, implement, and refine our multitiered, defense-in-depth approach to security, there are some solutions that you can adopt now as you begin your journey toward improving the state of your organization’s security:

• Design and enforce hygiene. Ensure that you have the governance in place to drive compliance. This includes controls, standards, and policies for the environment, applications, identity and access management, and elevated access. It’s also critical that standards and policies are continually refined to reflect changes in environments and security threats. Implement governance and compliance to enforce least-privileged access. Monitor resources and applications for ongoing compliance and ensure that your standards remain current as roles evolve.
• Implement least-privileged access. Using proper RBAC approaches with an emphasis on providing access only to what is absolutely required is the concept of least-privileged access. Add the necessary access controls to remove the need for Global Administrator or Domain Administrator access. Just provide everyone with the access that they truly need. Build your applications, environments, and tools to use RBAC roles, and clearly define what each role can and can’t do.
• Remove all persistent access. All elevated access should require JIT elevation. It requires an extra step to get temporary secure access before performing elevated-privilege work. Setting persistent access to expire when it’s no longer necessary narrows your exposed attack surface.
• Provide isolated elevated-privilege credentials. Using an isolated identity substantially reduces the possibility of compromise after a successful phishing attack. Admin accounts without an inbox have no email to phish. Keeping the information-worker credential separate from the elevated-privilege credential reduces the attack surface.

Microsoft Services can help

Customers interested in adopting a defense-in-depth approach to increase their security posture might want to consider implementing Privileged Access Workstations (PAW). PAWs are a key element of the Enhanced Security Administrative Environment (ESAE) reference architecture deployed by the cybersecurity professional services teams at Microsoft to protect customers against cybersecurity attacks.

For more information about engaging Microsoft Services to deploy PAWs or ESAE for your environment, contact your Microsoft representative or visit the Cybersecurity Protection page.

Reaping the rewards

Over the last two years we’ve had an outside security audit expert perform a cyber-essentials-plus certification process. In 2017, the security audit engineers couldn’t run most of their baseline tests because the SAW was so locked down. They said it was the “most secure administrative-client audit they’ve ever completed.” They couldn’t even conduct most of their tests with the SAW’s baseline, locked configuration.

In 2018, the security audit engineer said: “I had no chance; you have done everything right,” and added, “You are so far beyond what any other company in the industry is doing.”

Also, in 2018, our SAW project won a CSO50 Award, which recognizes security projects and initiatives that demonstrate outstanding business value and thought leadership. SAW was commended as an innovative practice and a core element of the network security strategy at Microsoft.

Ultimately, the certifications and awards help validate our defense-in-depth approach. We are building and deploying the correct solutions to support our ongoing commitment to securing Microsoft and our customers’ and partners’ information. It’s a pleasure to see that solution recognized as a leader in the industry.

• Learn how we’re protecting high-risk environments with secure admin workstations.
• Read about implementing a Zero Trust security model at Microsoft.
• Learn more about how we manage Privileged Access Workstations.

Want more information? Email us and include a link to this story and we’ll get back to you.

Please share your feedback with us—take our survey and let us know what kind of content is most useful to you.

The post Improving security by protecting elevated-privilege accounts at Microsoft appeared first on Inside Track Blog.

Adopting rigorous design standards is helping Microsoft get better at something very important to the company—getting accessibility right inside its own walls.

Microsoft’s journey to transform its approach to accessibility started when Microsoft CEO Satya Nadella took the helm in 2014, says Tricia Fejfar, partner director of user experience in Microsoft Digital, the organization that powers, protects, and transforms Microsoft. Nadella sharpened the company’s focus on accessibility in 2017, when he penned a moving essay describing his experience raising a child with cerebral palsy.

“That really got us thinking about accessibility internally,” Fejfar says. “Employees are more productive and engaged when they have simple, easy-to-use tools, and accessibility is a very important part of that DNA.”

More than 1 billion people on the planet identify as having some form of a disability, so building experiences that are accessible to all Microsoft employees makes a difference every day.

“Being able to do my job at Microsoft based on my skills and not be blocked by my blindness has made a big difference in my life,” says Manish Agrawal, a senior program manager for the Accessibility team within Microsoft Digital.

Agrawal, who is blind, works to make Microsoft products more accessible to people with disabilities. It’s about creating an inclusive work environment where everyone can succeed.

“For me, it’s not just about making products accessible for Microsoft employees to help them get their work done,” he says. “It’s also about supporting employees with disabilities and ensuring that Microsoft builds a diverse and inclusive workforce across the spectrum of abilities.”

Fejfar adds, “Designing for and building experiences that reflect the diversity of the people who use them makes sure we put our people at the center of our work. Until people recognize that, and honor it in the work they do, they can’t begin to make sure what they build will take care of everyone’s needs.”

It’s about understanding why you build something and who will use it. Microsoft calls it being human-centric and customer obsessed.

“Building accessible experiences is not a compliance effort or a checklist of guidelines,” Fejfar says. “It’s about thinking of the user at all stages of the development process so you build usable, delightful, and cohesive end-to-end experiences.”

Hiring and supporting people with disabilities makes good sense for the company and helps attract top talent.

“Millennials choose employers who reflect their values, and diversity and inclusion are at the top of their list,” Fejfar says. “They make up 75 percent of the global workforce.”

Making a difference in the lives of people like Agrawal is what brings people to the Accessibility team, Fejfar says. “We’re here because we want to make sure the internal products that our employees use every day are accessible,” she says.

[Find out how building inclusive, accessible experiences at Microsoft is a catalyst for digital transformation. Learn how Microsoft enables remote work for its employees.]

Adopting a coherent design system

Nadella sharing his story led to a company-wide pivot toward accessibility and improving employability for people with disabilities at Microsoft. One of the initiatives connected to this goal was creating a set of coherence design standards that teams can use each time they builds new tools and services for employees.

“Using a coherent design language reduces engineering costs while increasing engineering efficiency,” Fejfar says. “That makes what we build predictable to our users, which increases engagement and builds trust.”

Microsoft Digital’s design system is built on top of Fluent, Microsoft’s externally facing design language, which makes it feel more like Microsoft.

“Building coherently means something very specific to us,” Fejfar says. “It means designing and coding accessible and reusable UI components, interaction patterns, brand, and other guidelines to build predictable experiences for our employees.”

These design standards have allowed Microsoft to not only consider accessibility as part of every internal project. They also consider accessibility at every step along the way, from idea, to construction, to release. That makes its products accessible to as wide a range of people as possible, which creates new opportunities and better experiences for everyone who works at Microsoft.

Accessible design benefits everyone

Agrawal cites closed captioning as an example of a widely useful accessibility tool that is now used for far more than helping people with hearing impairments watch TV or follow a presentation. Creative uses of the capability include helping audiences understand someone with a heavy accent, following along on TVs placed in loud environments like airports and bars, or allowing someone to watch TV while their partner sleeps.

In fact, closed captions or subtitles are so popular with the general population that game maker Ubisoft reported that more than 95 percent of the people who play their popular Assassin’s Creed Odyssey game keep subtitles turned on. “When you build for accessibility, you end up building a much more compelling product,” Agrawal says.

Moreover, it’s simply good business sense to ensure that talented people such as Agrawal are empowered to make a significant contribution to companies such as Microsoft.

“We need to make sure all the applications and experiences that we build empower everyone who works here to not only do their work, but to have full, rich experiences while they’re at work,” Fejfar says. “Without accessible tools, people can’t do their best work, and if people can’t do their best work, our company, our culture, and our customers are directly impacted.”

For a transcript, please view the video on YouTube: https://www.youtube.com/watch?v=XhN1tnBcYLo, select the “More actions” button (three dots icon) below the video, and then select “Show transcript.”

Designing new employee experiences

One telling example of Microsoft Digital’s coherent design approach to accessibility is Microsoft MyHub, a new one-stop shop for employees to get their “at work” stuff done at work, like getting worksite access, taking time off, checking stock rewards, and finding out what holidays are upcoming.

It was also vital to make sure the app experience would be fully accessible, says Bing Zhu, principal design manager in Microsoft Digital’s Studio UX team.

“Before we built the app, our employees had to deal with as many as five to eight different tools almost every day,” Zhu says. “Each experience was different than the last one, and not all of them were as accessible as we needed them to be.”

This fragmented experience was difficult for everyone to navigate and very hard to keep accessible for people with disabilities.

“We used our coherent design system to build a unified, consistent, and accessible experience for our employees,” Zhu says. “Using that as our guide, we were able to design an application that all Microsoft employees can use.”

Not only is Microsoft MyHub compliant with Web Content Accessibility Guidelines (WCAG), but it also received a strong usability grade by employees with a spectrum of vision disabilities.

Crucially, the new app was built with accessibility in mind at every stage of its development cycle, Agrawal says.

“We reviewed the design for every feature for accessibility and beta tested the app’s accessibility every time a new feature was implemented,” he says. “We made sure it was accessible for all of our users at each step in the development process.”

One example of how the team that built Microsoft MyHub was guided by Microsoft Digital’s coherence design system was in how it made every interaction and visual element accessible.

“Our coherence design system—which is an extension of Microsoft’s Fluent design system—alongside the accessibility guidance that we provide, helped the MyHub team start incorporating accessibility into their app from the get-go,” says Anna Zaremba, a senior designer on Microsoft Digital’s Coherence team. “Our coherence design system provides components with built-in accessibility that Microsoft Digital’s product teams, like the team that built MyHub, use to create their experiences.”

Work that makes a difference

It’s striking to hear employees in Microsoft Digital talk about the deep satisfaction they take from making products more accessible.

“The greatest reward is hearing from people who have benefitted from our work,” Zaremba says. “I really like the fact that we are doing work that helps the entire company and drives a greater awareness of accessibility.”

Though Microsoft is among the companies pushing hard to build accessibility into everything it does, there is still much work to do. One in 10 people who identify as having some form of disability don’t have the assistive technology they need to fully participate in work and society.

Going forward, Microsoft Digital will continue designing with accessibility as a top priority, using the developmental model it uses to build solutions like Microsoft MyHub as a template for creating the company’s next generation of employee tools.

“We’re still learning this process ourselves,” Zhu says. “We’re figuring out how to make accessibility and design work with program managers and engineers to create even more opportunities for access. It’s an exciting challenge.”

And one that will open doors for Microsoft employees—and others.

“I really love building software anyway,” Agrawal says. “But it’s great to be part of a team that is working to make Microsoft a more inclusive place to work. It has a real impact on people’s lives.”

• Learn more about creating an accessibility training program for your team.
• Dive into the latest accessibility fundamentals training course on Microsoft Learn.
• October is National Disability Employment Awareness Month 2020—learn more about the 75th anniversary of this event in the US here.
• Read how Microsoft is sharing how many of its employees identify as having some form of disability.
• Read how people with disabilities shape technology people use every day.
• Find out how building inclusive, accessible experiences at Microsoft is a catalyst for digital transformation.
• Learn how Microsoft enables remote work for its employees.

The post Microsoft’s fresh approach to accessibility powered by inclusive design appeared first on Inside Track Blog.

Microsoft’s cloud-first strategy enables most Microsoft employees to directly access applications and services via the internet, but remote workers still use the company’s virtual private network (VPN) to access some corporate resources and applications when they’re outside of the office.

This became increasingly apparent when Microsoft prepared for its employees to work remotely in response to the global pandemic. VPN usage increased by 70 percent, which coincides with the significant spike in users working from home daily.

So then, how is Microsoft ensuring that its employees can securely access the applications they need?

With split tunneling and a Zero Trust security strategy.

As part of the company’s Zero Trust security strategy, employees in Microsoft Digital Employee Experience (MDEE) redesigned the VPN infrastructure by adopting a split-tunneled configuration that further enables the company’s workloads moving to the cloud.

“Adopting split tunneling has ensured that Microsoft employees can access core applications over the internet using Microsoft Azure and Microsoft Office 365,” says Steve Means, a principal cloud network engineering manager in MDEE. “This takes pressure off the VPN and gives employees more bandwidth to do their job securely.”

Eighty percent of remote working traffic flows to cloud endpoints where split tunneling is enabled, but the rest of the work that employees do remotely—which needs to be locked down on the corporate network—still goes through the company’s VPN.

“We need to make sure our VPN infrastructure has the same level of corporate network security as applications in the cloud,” says Carmichael Patton, a principal security architect on Microsoft’s Digital Security and Resilience team. “We’re applying the same Zero Trust principles to our VPN traffic, by applying conditional access to each connection.”

[Learn how Microsoft rebuilt its VPN infrastructure. Learn how Microsoft transitioned to modern access architecture with Zero Trust. Read how Microsoft is approaching Zero Trust Networking.]
For a transcript, please view the video on YouTube: https://www.youtube.com/watch?v=bleFoL0NkVM, select the “More actions” button (three dots icon) below the video, and then select “Show transcript.”

Securing remote workers with device management and conditional access

Moving most of the work that employees require to the cloud only became possible after the company adopted modern security controls that focus on securing devices.

“We no longer rely solely on the network to manage firewalls,” Patton says. “Instead, each application that an employee uses enforces its own security management—this means employees can only use an app after it verifies the health of their device.”

To support this transformed approach to security, Microsoft adopted a Zero Trust security model, which manages risk and secures working remotely by managing the device an employee uses.

“Before an employee can access an application, they must enroll their device, have relevant security policies, and have their device health validated,” Patton says. “This ensures that only registered devices that comply with company security policies can access corporate resources, which reduces the risk of malware and intruders.”

The team also recommends using a dynamic and scalable authentication mechanism, like Azure Active Directory, to avoid the trouble of certificates.

While most employees rely on our standard VPN infrastructure, Microsoft has specific scenarios that call for additional security when accessing company infrastructure or sensitive data. This is the case for MDEE employees in owner and contributor roles that are configured on a Microsoft Azure subscription as well as employees who make changes to customer-facing production services and systems like firewalls and network gear. To access corporate resources, these employees use Privileged Access Workstations, a dedicated operating system for sensitive tasks, to access a highly secure VPN infrastructure.

Phil Suver, a principal PM manager in MDEE, says working remotely during the global pandemic gives employees a sense of what the Zero Trust experience will be like when they return to the office.

“Hardened local area networks that previously accessed internal applications are a model of the past,” Suver says. “We see split tunneling as a gateway to prepare our workforce for our Zero Trust Networking posture, where user devices are highly protected from vulnerability and employees use the internet for their predominant workload.”

It’s also important to review your VPN structure for updates.

“When evaluating your VPN configuration, identify the highest compliance risks to your organization and make them the priority for controls, policies, and procedures,” Patton says. “Understand the security controls you give up by not flowing the connections through your internal infrastructure. Then, look at the controls you’re able to extend to the clients themselves, and find the right balance of risk and productivity that fits your organization.”

Keeping your devices up-to-date with split tunneling

Enterprises can also optimize patching and manage update compliance using services like Microsoft Endpoint Manager, Microsoft Intune, and Windows Update for Business. At Microsoft, a split-tunneled VPN configuration allows these services to keep devices current without requiring a VPN tunnel to do it.

“With a split-tunneled configuration, update traffic comes through the internet,” says Mike Carlson, a principal service engineering manager in MDEE. “This improves the user experience for employees by freeing up VPN bandwidth during patch and release cycles.”

At Microsoft, device updates fall into two categories: feature updates and quality updates. Feature updates occur every six months and encompass new operating system features, functionality, and major bug fixes. In contrast, monthly quality updates include security and reliability updates as well as small bug fixes. To balance both user experience and security, Microsoft’s current configuration of Windows Update for Business prompts Microsoft employees to update within 48 hours for quality updates and 7 days for feature updates.

“Not only can Windows Update for Business isolate update traffic from the VPN connection, but it can also provide better compliance management by using the deadline feature to adjust the timing of quality and feature updates,” Carlson says. “We can quickly drive compliance and have more time to focus on employees that may need additional support.”

Evaluating your VPN configuration

When your enterprise evaluates which VPN configuration works best for your company and users, you must evaluate their workflows.

“Some companies may need a full tunnel configuration, and others might want something cloud-based,” Means says. “If you’re a Microsoft customer, you can work with your sales team to request a customer engagement with a Microsoft expert to better understand our implementation and whether it would work for your enterprise.”

Means also said that it’s important to assess the legal requirements of the countries you operate in, which is done at Microsoft using Azure Traffic Manager. For example, split tunneling may not be the right configuration for countries with tighter controls over how traffic flows within and beyond their borders.

Suver also emphasized the importance of understanding the persona of your workforce, suggesting you should assess the workloads they may need to use remotely and their bandwidth capacity. You should also consider the maximum number of concurrent connections your VPN infrastructure supports and think through potential seasonal disruptions.

“Ensure that you’ve built for a snow day or a pandemic of a global nature,” Suver says. “We’ve had to send thousands of customer support agents to work from home. Typically, they didn’t use VPN to have voice conversations with customers. Because we sized and distributed our infrastructure for a global workforce, we were able to quickly adapt to the dramatic shift in workloads that have come from our employees working from home during the pandemic. Anticipate some of the changes in workflow that might occur, and test for those conditions.”

It’s also important to collect user connection and traffic data in a central location for your VPN infrastructure, to use modern visualization services like Microsoft Power BI to identify hot spots before they happen, and to plan for growth.

Means’s biggest piece of advice?

Focus on what your enterprise needs and go from there.

“Identify what you want to access and what you want to protect,” he says. “Then build to that model.”

Tips for retooling VPN at your company

Azure offers a native, highly-scalable VPN gateway, and the most common third-party VPN and Software-Defined Wide Area Network virtual appliances in the Azure Marketplace.

For more information on these and other Azure and Office network optimizing practices, please see:

• Office Connectivity Principles
• Network considerations for Teams
• Azure OpenVPN client
• Azure VPN Gateways
• Azure Point-to-site VPN
• VPN Network Virtual Appliances in the Azure Marketplace
• Publishing web applications using Azure Active Directory’s Application Proxy
• VPN split tunneling for Office 365
• How-to guides for common VPN platforms
• Updates for improving work-from-home employee access

• Here are some alternative ways for security professionals and IT to achieve modern security controls in remote work scenarios.
• Check our best practices and guidelines for security professionals on how to work remotely and stay secure.

Here are additional resources to learn more about how Microsoft applies networking best practices and supports a Zero Trust security strategy:

• Learn how Microsoft rebuilt its VPN infrastructure.
• Learn how Microsoft transitioned to modern access architecture with Zero Trust.
• Read how Microsoft is approaching Zero Trust Networking.

The post Using a Zero Trust strategy to secure Microsoft’s network during remote work appeared first on Inside Track Blog.

Underneath those broad strokes, we serve very specific, complex customers.

One set of such customers is in the federal sector, where the specific regulatory requirements of sovereign entities—such as the Department of Defense (DoD) in the US—require that we create highly secure environments that adhere to the Cybersecurity Maturity Model Certification (CMMC) standard. (CMMC is an intermediate cybersecurity certification for defense contractors that focuses on protecting controlled unclassified information through enhanced cyber hygiene practices.)

Building environments that meet the CMMC standard presents unique opportunities and challenges, especially when it comes to managing complex collaboration scenarios at scale while also ensuring the security of our customers’ confidential information.

To help us get this right, we build environments for our customers that employ our Zero Trust security model, which means operating on a “never trust, always verify” principle. This enables us to deliver secure platform tools, networks, elastic computing, and storage options. It also helps provide our customers with better collaboration and business operations tools.

This works for governments, their military and intelligence agencies, and goes beyond the high standards of our usual customers.

To specifically address these unique needs within Microsoft, we have created a specialized IT environment, called the Federal Government Operating Environment or Microsoft FedNet. Powered by Azure for Government and Microsoft 365 Government, this environment is carefully designed to match the complex requirements of our US Federal and US Defense Industrial Base clients.

Serving as Customer Zero

In this story, we’ll explain some of the unique challenges we faced internally as we implemented this “company within a company” to allow our employees to work easily across both our traditional corporate environment (CorpNet) and the more highly regulated environment (FedNet) that we use to support our US Federal customers.

We have a strong value around being Customer Zero for our products, so much so that we implement them the way we would suggest our customers use them, so we can experience the customer reality firsthand. While living on the edge of this innovation knife can be unsettling at times, it allows us to be first to encounter challenges our customers might face. As such, we become a valuable feedback loop back to our product teams, which speeds up the innovation cycle and lowers barriers to entry for actual customers.

It was absolutely essential that we deliver a product for our federal customers that met or exceeded the experience that our own team expected. This is the critical benefit of our Customer Zero approach to engineering—we live and breathe the product long before it reaches an external user. That gives us time to explore and refine the customer experience to be as good as can be.

— Jason Zander, executive vice president, Strategic Missions and Technologies

Cross function, cross company

At Microsoft, our commitment to creating a dedicated environment for highly regulated workloads was not just about establishing a separate space; it was about embodying a cloud-first and deeply integrated approach across our entire business spectrum. This strategic decision was pivotal in aligning our expansive scale with the nuanced demands of compliance-focused sectors.

To get this right, our comprehensive, multi-disciplinary strategy coalesced around rethinking our sales pipeline management, financial systems, modernizing commerce tools, refining our support services, and evolving our internal engineering practices. This cross-organizational synergy was crucial to ensure that every aspect of our business supported and benefited from this new initiative.

“It was absolutely essential that we deliver a product for our federal customers that met or exceeded the experience that our own team expected,” says Jason Zander, our executive vice president of Strategic Missions and Technologies. “This is the critical benefit of our Customer Zero approach to engineering—we live and breathe the product long before it reaches an external user. That gives us time to explore and refine the customer experience to be as good as can be.”

Embracing a growth mindset, we aimed to merge the insights gained from operating a $3 trillion-dollar company with our profound understanding of servicing compliance-intensive customers. This fusion of scale and specialization was geared not only toward meeting existing needs but also toward innovating in novel and impactful ways.

Our workday began by signing in to this secure environment, using Microsoft 365 applications for our daily tasks, and collaborating through Teams. This wasn’t just a separate project; it was a complete shift in our work environment. We effectively isolated ourselves within a secure bubble, distinct from the rest of Microsoft, to ensure we could operate seamlessly as an independent entity.

— Dwight Jones, principal product manager, Microsoft Federal team, Microsoft Digital

Through this transformative journey, we have not only tailored our offerings to meet the stringent requirements of highly regulated sectors, but we have also significantly enhanced our overall business intelligence. By internalizing and refining our products early in their lifecycle, we ensure that our services not only align with but surpass the expectations of our most compliance-conscious customers, continuing our legacy as a global leader in technology solutions.

What does this mean in the real world?

In our journey to develop a more secure platform for internal use at Microsoft, we took an unconventional and immersive approach; we essentially created a new federal entity within our larger corporate organization, where the creators and users of this platform merged into one. Our team, dedicated to building this secure environment, began to experience their daily work lives within FedNet, taking meetings on Microsoft Teams and using document collaboration across Microsoft 365 and ensuring its functionality and reliability firsthand.

“Our workday began by signing in to this secure environment, using Microsoft 365 applications for our daily tasks, and collaborating through Teams,” says Dwight Jones, a principal product manager on the Microsoft Federal team in Microsoft Digital (MSD), our IT division. “This wasn’t just a separate project; it was a complete shift in our work environment. We effectively isolated ourselves within a secure bubble, distinct from the rest of Microsoft, to ensure we could operate seamlessly as an independent entity.”

This shift represented a significant change in our corporate experience.

By establishing secure Microsoft tenants in the Azure Government Community Cloud’s high-security environment, we created what we call “Microsoft Federal”—a company within a company. This bold move came with its own set of challenges, but it was essential. It enabled us to not just theorize but practically test and enhance our FedNet solution in real-world conditions, ensuring its effectiveness for our sovereign customers.

Such an approach was pivotal in validating the reliability and security of our solution. It allowed us to experience the potential challenges our customers might face and address them proactively. Ultimately, this real world experiment was more than just a test; it was a commitment to delivering a product that we ourselves could rely on and trust, setting a new standard in our offerings to highly regulated sectors.

Microsoft Federal is a prime example of the potential in public-private partnerships. We bring our expertise to key government organizations, offering them advanced, secure solutions to succeed in their missions. Together, we’re shaping the future of network security.

— Jason Zander, executive vice president, Strategic Missions and Technologies

Getting security right

The key distinction between our traditional business and our new Federal sector business model lies in the stringent regulatory constraints from agencies like the US Department of Defense, adhering to CMMC level 2. Our FedNet environment is designed to not just meet but exceed these standards. In fact, our FedNet implementation has achieved a perfect score (Microsoft Federal Successfully Completes Voluntary CMMC Assessment), reflecting our security team’s commitment to the highest standards, covering a broad range of customer requirements.

“Microsoft Federal is a prime example of the potential in public-private partnerships,” Zander says. “We bring our expertise to key government organizations, offering them advanced, secure solutions to succeed in their missions. Together, we’re shaping the future of network security.”

To align with our Zero Trust principles in FedNet, we started by enhancing device endpoint security using a combination of Microsoft Conditional Access and Microsoft Azure Virtual Desktop (AVD). This provides our teams with secure and controlled virtual access to standard collaboration and productivity capabilities, a shift from the traditional physical machine setup in our corporate environment.

While aligning with our cloud-first strategy, this transition posed challenges.

The virtual environment offered less flexibility than a commercially managed machine, particularly in terms of software installation control. In our commercial environments, users can install a variety of first- and third-party applications to enable them to be productive. To comply with more stringent regulations, we highly regulate what applications can be installed on the virtual client—each piece of software has to be security cleared by our Security Portal for Assessment, Consulting and Engineering (ACE) tool—we had to create controlled processes to qualify each piece of software we deployed in our FedNet environment.

Teams is the lifeblood of collaboration at Microsoft, even a few-second delay in a Teams call hosted in our AVD environment can significantly disrupt the experience for our users in Microsoft Federal, just as it would for any other user.

— Dwight Jones, principal product manager, Microsoft Federal team, Microsoft Digital

Getting to product parity

Getting back to our internal team charged with deploying a version of this platform inside the company, our internal users at Microsoft Federal need more than just robust compute platforms and Zero Trust technology—they require the same modern communication and productivity tools as any of our other employee to manage daily operations effectively. Despite differing security protocols, essential tools like Microsoft Teams and Microsoft Outlook must function just as reliably for our Microsoft Federal users as they do for our CorpNet users.

Take Microsoft Teams meetings, for example.

“Teams is the lifeblood of collaboration at Microsoft, even a few-second delay in a Teams call hosted in our AVD environment can significantly disrupt the experience for our users in Microsoft Federal, just as it would for any other user,” Jones says.

Such technical issues, if unresolved, could hinder business operations and negatively impact user perception of our products. We recognized the need for improvement in how Teams integrated within AVD highlighting key opportunities to accelerate quality of service features across both products that, once implemented, would quickly trickle down to all users of these services.

The complexity of managing change

Not surprisingly, we found that managing change and expectations was as significant a challenge as the technical blockers. The biggest hurdle became managing the cognitive shift when moving between environments, rather than addressing technical gaps. For instance, implementing data loss prevention strategies via document labeling was optional in our commercial environment but mandatory in FedNet to comply with CMMC regulations. This necessitated a new approach to data handling and required significant adjustments from our users. Training users on the rational and procedures for data handling was critical to overcome this barrier to entry for new users.

Our Microsoft Federal environment, while more secure, should not lack any functionality or features compared to the civilian version.

— Dwight Jones, principal product manager, Microsoft Federal team, Microsoft Digital

Experiment, learn, adjust, grow

After establishing the basic functionality needed for our Microsoft Federal employees to most closely match the experience of their counterparts in the larger Microsoft organization, our focus shifted to optimizing the environment. This entailed refining existing solutions and introducing the latest innovations Microsoft is known for.

It was all about feature parity.

“Our Microsoft Federal environment, while more secure, should not lack any functionality or features compared to the civilian version,” Jones says.

A standout feature attracting global corporate interest in FedNet is Microsoft Teams Rooms. This innovative setup combines built-in screens, modern video cameras, eye-tracking technology, and Zero Trust security to revolutionize meeting experiences in Microsoft Teams, specifically tailored for our Microsoft Federal product.

Serving some of the world’s most security-conscious customers grants us unique experiences and insights that benefit our entire business. With exciting features and products, many fueled by Microsoft’s AI innovations, we’re charting a bright future for all our customers, including those in Microsoft Federal. This is how we fulfill our mission to empower every person and organization on the planet to achieve more.

— Jason Zander, executive vice president, Strategic Missions and Technologies

“Secure Teams Rooms is exactly what our internal Microsoft Federal users, and indeed any organization, would desire,” Jones says.

Following this, we began a pilot rollout of Microsoft Teams Rooms in select secure locations, with plans to extend this enriched experience to all employees in the Microsoft Federal environment. By using the same technologies they provide to customers, our employees gain valuable insights and experiences, enhancing their ability to support customers deploying Microsoft Teams Rooms in their organizations.

“Serving some of the world’s most security-conscious customers grants us unique experiences and insights that benefit our entire business,” Zander says. “With exciting features and products, many fueled by Microsoft’s AI innovations, we’re charting a bright future for all our customers, including those in Microsoft Federal. This is how we fulfill our mission to empower every person and organization on the planet to achieve more.”

Microsoft Federal and our experience building a company within a company exemplifies our commitment to empowering customers with secure, compliant, and innovative solutions. By harnessing technologies like Microsoft Teams, Azure, and Microsoft 365, we’re setting new standards for collaboration and security in government and beyond.

Here are some things to think about as you consider beefing up your security with a product like our FedNet solution:

• Zero Trust is now relevant to everyone: Hybrid work, cloud migration, and increased threats make taking a Zero Trust approach to security a prudent consideration in every organization.
• Lack of leadership alignment is the biggest obstacle to driving Zero Trust agendas: Leadership alignment is critical to driving Zero Trust agendas. It’s important to ensure that all stakeholders are aligned with the Zero Trust vision and understand how it fits into the broader security strategy. This includes executive leadership, IT teams, security teams, and other business units.
• Zero Trust architecture requires holistic, integrated thinking: Zero Trust architecture requires a holistic, integrated approach that spans people, processes, and technology. It’s important to have a clear understanding of your organization’s assets, data flows, and user behaviors in order to design an effective Zero Trust architecture.

Learn more about our Microsoft Federal program and offerings.

• Explore implementing a Zero Trust security model at Microsoft.
• Unpack culture, the cloud, and security: learning from Microsoft’s digital transformation.
• Discover enhancing Microsoft’s security posture with Microsoft Azure Firewall Manager.

Want more information? Email us and include a link to this story and we’ll get back to you.

Please share your feedback with us—take our survey and let us know what kind of content is most useful to you.

The post Sharing what we learned deploying our secure federal environment appeared first on Inside Track Blog.

The episodes cover how security leaders are adjusting to the new normal of hybrid work. In each episode, Arsenault and his guest share practical tips and strategies such as using a Zero Trust approach, that enterprises can start using today to make sure employees are productive, secure, and healthy no matter if they’re at the office, at home or anywhere in-between.

Episode 1: Securing the Cloud with Mark Russinovich

To kick off the podcast, Arsenault chats with Mark Russinovich, chief technology officer of Microsoft Azure, about the power of cloud technology and how it’s used to advance technology in the world of remote and hybrid work.

Listen to Episode 1 of Security Unlocked here.

Episode 2: Securing Hybrid Work with Venki Krishnababu

Arsenault sits down with Venki Krishnababu, senior vice president of Global Technology Services at Lululemon, to discuss the tools, practices, and technology to help the company seamlessly shift to remote work at their companies and beyond.

Listen to Episode 2 of Security Unlocked here.

Episode 3: The Human Side of Hybrid Work with Amy Coleman

With over 175,000 employees around the world across 100 countries and regions, Arsenault knows that it’s no small feat to shift to remote work. Microsoft Corporate Vice President Amy Coleman talks with him about the company’s plan to support hybrid work, and how managers can support this transition.

Listen to Episode 3 of Security Unlocked here.

Episode 4: Leading an Inclusive Workforce with Vodafone Global Cybersecurity Director Emma Smith

Teamwork makes the dream work, but so does support from managers, supervisors, and global security directors. Arsenault chats with Emma Smith, Director of Global Cybersecurity for Vodafone, about returning to in-person work after over a year of being remote, and some of the challenges that come with this transition. You’ll leave with key points for security practitioners and tips for securing your hybrid workspace and hybrid workforce.

Listen to Episode 4 of Security Unlocked here.

Episode 5: Building a Stronger Security Team with LinkedIn CISO Geoff Belknap

Arsenault talks with Geoff Belknap, colleague and fellow CISO at LinkedIn, about what it means to build a team, not of experts, but of intrepid thinkers willing to learn something new and invest in themselves to grow. Learn more about how to address the cybersecurity gender gap, the interdisciplinary nature of security, and the importance of investing in your team’s growth.

Listen to Episode 5 of Security Unlocked here.

Episode 6: Developing Influential Security Leaders with TikTok CSO Roland Cloutier

Success can be measured in a lot of different ways, whether it’s productivity, department growth, increased team morale, and more. In the case of TikTok CSO Roland Cloutier, he focuses on how many people under his leadership have eventually worked their way up to become CISOs. In this episode, he shares how the military granted him the discipline to excel in the world of cybersecurity, and the leadership skills to provide opportunities for those around him to find just as much success.

• Listen to Episode 6 of Security Unlocked here.
• Watch this video to learn best practices for implementing Zero Trust at Microsoft.
• Read about how Microsoft is implementing a Zero Trust security model.
• Find out more about how Microsoft secures its network with a Zero Trust model.

The post Microsoft CISO Bret Arsenault provides practical advice to secure your hybrid workspace appeared first on Inside Track Blog.

We recently implemented Microsoft Sentinel to replace a preexisting, on-premises solution for security information and event management (SIEM). With Microsoft Sentinel, we can ingest and appropriately respond to more than 20 billion cybersecurity events per day.

Microsoft Sentinel supplies cloud-scale SIEM functionality that allows integration with crucial systems, provides accurate and timely response to security threats, and supports the SIEM requirements of our team.

Our team is responsible for maintaining security and compliance standards across Microsoft. Managing the massive volume of incoming security-related data is critical to Microsoft’s business health. Historically, we have performed SIEM using a third-party tool hosted on-premises in Microsoft datacenters.

However, we recognized several areas in which they could improve their service by implementing a next-generation SIEM tool. Some of the challenges when using the old tool included:

• Limited ability to accommodate increasing incoming traffic. Ingesting data into the previous SIEM tool was time consuming due to limited ingestion processes. As the number of incoming cybersecurity events continued to grow, it became more evident that the solution we were using wouldn’t be able to maintain the necessary throughput for data ingestion.
• On-premises scalability and agility issues. The previous solution’s on-premises nature limited our ability to scale effectively and respond to changing business and security requirements at the speed that we required.
• Increased training requirements. We needed to invest more resources in training and onboarding with the previous solution, because it was on-premises and customized to meet our requirements. If we recruited employees from outside Microsoft, they needed to learn the new solution—including its complex on-premises architecture—from the ground up.

As part of our ongoing digital transformation, we’re moving to cloud-based solutions with proven track records and active, customer-facing development and involvement. We need our technology stack to evolve at the speed of our business.

[Read more about how we’re securing our enterprise and responding to cybersecurity attacks with Microsoft Sentinel. | Discover how we’re improving our security by protecting elevated-privilege accounts at Microsoft.]

Modernizing SIEM with Microsoft Sentinel

In response to the challenges presented, we began assessing options for a new SIEM environment that would address the challenges positioning our team to manage continued growth of the cybersecurity landscape.

Feature assessment and planning

In partnership with the Microsoft Sentinel product team, our internal security division assessed whether Sentinel would be a suitable replacement for our previous solution. Sentinel is a Microsoft-developed, cloud-native enterprise SIEM solution that uses the cloud’s agility and scalability to ensure rapid threat detection and response through:

• Elastic scaling.
• AI–infused detection capability.
• A broad set of out-of-the-box data connectivity and ingestion solutions.

To move to Microsoft Sentinel, we needed to verify that equivalent features and capabilities were available in the new environment. We aligned security teams across Microsoft to ensure that we met all requirements. Some of these teams had mature monitoring and detection definitions in place, and we needed to understand those scenarios to accommodate feature-performance requirements. The issues that our previous solution presented narrowed our focus with respect to whether Sentinel would work, including throughput, agility, and usability.

Throughout the assessment period and into migration, we worked closely with the Microsoft Sentinel product team to ensure that Microsoft Sentinel could provide the feature set we required. Our engagement with the Microsoft Sentinel team addressed two sets of needs simultaneously. We received significant incident-response benefits from Microsoft Sentinel while the product team worked with us as if we were a customer. This close collaboration meant that the product team could identify what enterprise-scale customers needed more quickly.

Not only were our requirements met, but we were able to provide feedback and testing for the Microsoft Sentinel product team. This helped them better serve their large customers that have similar challenges, requirements, and needs.

Defining and refining SIEM detections

As we developed standards that met our new requirements, we also evaluated our previous SIEM solution’s functionality to determine how it would transition to Microsoft Sentinel. We examined three key aspects of incoming security data ingestion and event detection:

• Data-source validity. We pull incoming SIEM data from hundreds of data locations across Microsoft. As time has passed, some of these data sources remained valid but others no longer provided relevant SIEM data. We assessed our entire data-source footprint to determine which data sources Microsoft Sentinel should ingest and which ones were no longer required. This process helped us to better understand our data-source environment and refine the amount of data ingested. There were several data sources that we weren’t ingesting with the previous solution because of performance limitations. We knew that we wanted to increase ingestion capability when moving to Microsoft Sentinel.
• Detection importance. Our team examined event-detection definitions used throughout the previous SIEM solution, so we could understand how detections were being performed, which detection definitions generated alerts, and the volume of alerts from each detection. This information helped us identify the most important detection definitions, so we could prioritize these definitions in the migration process.
• Detection validity. Our security teams evaluated the list of detections from our SIEM environment so we could identify invalid detections or detection definitions that required refinement. This helped us create a more streamlined set of detections when moving into Microsoft Sentinel, including combining multiple detection definitions and removing several detections.

Throughout this process, we worked with the Microsoft Security Operations team to evaluate detections end-to-end. They got involved in the detection and data-source refinement process and were exposed to how these detections and data sources would work in Microsoft Sentinel.

Implementation

After feature parity and throughput capabilities were confirmed, we began the migration process from our previous solution to Microsoft Sentinel. Based on our initial testing, we added several implementation steps to ensure that our Sentinel environment would readily meet our security environment’s needs.

Onboarding data sources

Properly onboarding data sources was a critical component in our implementation and one of the biggest benefits of the Microsoft Sentinel environment. With the massive amount of default connectors available in Sentinel, we were able to connect to most of our data sources without further customization. This included cloud data sources such as Microsoft Azure Active Directory, Microsoft Defender for Cloud, and Microsoft Defender. However, it also included on-premises data sources, such as Windows Events and firewall systems.

We also connected to several enrichment sources that supplied more information for threat-hunting queries and detections. These enrichments sources included data from human-resources systems and other nontypical data sources. We used playbooks to create many of these connections.

We keep Microsoft Sentinel data in hot storage for 90 days, using Kusto Query Language (KQL) queries for detections, hunting, and investigation. We also use Microsoft Azure Data Explorer for warm storage and Microsoft Azure Data Lake for cold storage and retrieval for up to two years.

Refining detections

Based on testing, we refined our detection definitions further in Sentinel to support better alert suppression and aggregation. We didn’t want to overwhelm our Security Operations team with incidents. Therefore, we refined our detection definitions to include suppression logic when notification wasn’t required and aggregation logic to ensure that similar and related events were grouped together and not surfaced as multiple, individual alerts.

Increasing scale with the cloud

We used dedicated clusters for Microsoft Azure Monitor Log Analytics to support the data-ingestion scalability we required. At a large enterprise scale, our previous solution was exceeding its capacity at 10 billion events per day. With dedicated clusters, we were able to accommodate that initial volume and add additional data sources to improve alert detection, thereby increasing our event ingestion to > 20 billion events per day.

Customizing functionality

Our environment required several customizations to Sentinel functionality, which we implemented by using standard Microsoft Sentinel features and extension capabilities to meet our needs while still staying within the boundaries of standard functionality. Using common features for customization made our changes to Sentinel easy to document and helped our security operations team better and more quickly understand and use the new features. We made several important customizations including:

• Integration with our IT service-management system. We integrated Microsoft Sentinel with our security incident management solution. This had a two-fold positive effect, as it extended Sentinel information into our case-management environment and provided our support teams with exactly the information they need, regardless of which tool they’re in.
• Implementation of Microsoft Defender for Cloud playbook to support scale. We used a playbook to automate the addition of more than 20,000 Azure subscriptions to Microsoft Defender for Cloud.
• High volume ingestion with Microsoft Azure Event Hub and Microsoft Azure Virtual Machine scales sets. We built a custom solution that ingested the large volume of events from our firewall systems that exceeded the capabilities of on-premises collection agents. With the new solution, we can ingest more than 100,000 events per second into Microsoft Sentinel from on-premises firewalls.

We’ve experienced several important benefits from using Microsoft Sentinel as our SIEM tool, including:

• Faster query performance. Our query speed with Microsoft Sentinel improved drastically. It’s 12 times faster than it was with the previous solution, on average, and is up to 100 times faster with some queries.
• Simplified training and onboarding. Using a cloud-based, commercially available solution like Microsoft Sentinel means it’s much simpler to onboard and train employees. Our security engineers don’t need to understand the complexities of an underlying on-premises architecture. They simply start using Sentinel for security management.
• Greater feature agility. Microsoft Sentinel’s feature set and capabilities iterate at a much faster rate than we could maintain with our on-premises developed solution.
• Improved data ingestion. Microsoft Sentinel’s out-of-the box connectors and integration with the Microsoft Azure platform make it much easier to include data from anywhere and extend Sentinel functionality to integrate with other enterprise tools. On average, it’s 18 times faster to ingest data into Sentinel using a built-in data connector than it was with our previous solution.

Throughout our Microsoft Sentinel implementation, we reexamined and refined our approach to SIEM. At Microsoft’s scale, very few implementations go exactly as planned from beginning to end. However, we derived several points with our Sentinel implementation, including:

• More testing enables more refinement. We tested our detections, data sources, and processes extensively. The more we tested, the better we understood how we could improve test results. This, in turn, meant more opportunities to refine our approach.
• Customization is necessary but achievable. We capitalized on the flexibility of Microsoft Sentinel and the Microsoft Azure platform often during our implementation. We found that while out-of-the-box features didn’t meet all our requirements, we were able to create customizations and integrations to meet the needs of our security environment.
• Large enterprise customers might require a dedicated cluster. We used dedicated Log Analytics clusters to allow ingestion of nearly 20 billion events per day. In other large enterprise scenarios, moving from a shared cluster to a dedicated cluster might be necessary for adequate performance.

The first phase of our migration is complete! However, there’s still more to discover with Microsoft Sentinel. We’re taking advantage of new ways to engage and interact with connected datasets and using machine learning to manage some of our most complex detections. As we continue to grow our SIEM environment in Sentinel, we’re capitalizing on Sentinel’s cloud-based benefits to help meet our security needs at an enterprise level. Sentinel provides our security operations teams with a single SIEM solution that has all the tools they need to successfully complete and manage security events and investigations.

• Read more about how we’re securing our enterprise and responding to cybersecurity attacks with Microsoft Sentinel.
• Discover how we’re improving our security by protecting elevated-privilege accounts at Microsoft.

Want more information? Email us and include a link to this story and we’ll get back to you.
Please share your feedback with us—take our survey and let us know what kind of content is most useful to you.

The post Moving to next-generation SIEM at Microsoft with Microsoft Sentinel appeared first on Inside Track Blog.

Powered by Microsoft’s internal security team, our Zero Trust model centers on strong identity, least-privilege access, device-health verification, and service-level control and telemetry across the entire IT infrastructure. Our networking leadership and engineering teams are building a network to support the Zero Trust model. It includes fully integrated authentication across all network devices, effective segmentation of our global network, end-to-end encrypted connectivity, and intelligent monitoring.

Zero Trust networking is a journey; we’ve come a long way, and we’ve learned valuable lessons. In this article, we share these lessons with you to help you plan and deploy Zero Trust networking effectively and efficiently in your environment.

[To read more about the leadership lessons from our Zero Trust networking deployment, visit Zero Trust networking: Sharing lessons for leaders. | Check out Microsoft’s digital security team answers your Top 10 questions on Zero Trust. | Discover using a Zero Trust strategy to secure Microsoft’s network during remote work. | Read more about Running on VPN: How Microsoft is keeping its remote workforce connected.]

Primary goals

Our engineering goals for Zero Trust followed the general scope of the primary functions of Zero Trust, and they established how we approached the implementation of Zero Trust networking.

• Understand devices and environment. Accurate information is critical to effective implementation. We had to understand the state of devices on our network before, during, and after deployment.
• Design for inherent security. Zero Trust networking is about a security posture. Our planning and design always included security as an intrinsic priority.
• Deploy and manage with automation. We didn’t have the time or resources to reconfigure our entire network manually. Our deployment and management used automation wherever possible, relying heavily on virtual networking and network as code.
• Optimize costs. Refactoring the entire network involves a massive amount of infrastructure. We focused on optimizing costs as we implemented, reusing infrastructure when we could.
• Maintain a consistent user experience. We wanted the transition to Zero Trust networking to be as noninvasive to the user as possible, while placing all devices in a more secure and controlled environment.

These goals directly influenced our implementation and molded our approach to specific inventory, design, deployment, and monitoring efforts throughout Zero Trust Networking.

Implementation considerations

For something as critical as a Zero Trust networking implementation, we needed to use our own network and security experts; we couldn’t outsource that intellectual property. We allocated these resources early and dedicated our best and brightest minds to critical decisions and tasks.

Zero Trust networking requires a reassessment of any organization’s network operations. At Microsoft, we’re making fundamental changes to a network that hosts more than 1 million devices.

—David Lef, principal IT enterprise architect, Microsoft Digital

Although high-level goals established at the leadership level drove the entire Zero Trust implementation, we didn’t expect our leadership to make every decision. As objectives and decisions became more defined, we found it best to address issues and make decisions at the feature-team level. This model helped us react quickly to issues that arose and maintain project timelines despite obstacles.

Understanding the environment

Zero Trust networking forced us to comprehensively change our network infrastructure, from the edge to the wide-area network (WAN), and from remote users to in-building wired and wireless experiences. We had to make sure that we fully understood our existing infrastructure on several different levels: what equipment was in the field, how our network was supporting critical business processes, and what changes were required to support Zero Trust networking properly.

“Zero Trust networking requires a reassessment of any organization’s network operations. At Microsoft, we’re making fundamental changes to a network that hosts more than 1 million devices,” says David Lef, a principal IT enterprise architect in MSD.

Creating a framework for network inventory

Zero Trust networking has a vast scope, affecting more than 1 million devices using our network. Building a framework and a strategy for creating this inventory was critical to making informed decisions for planning and deployment.

End-user devices play an essential role in Zero Trust networking, but so do the infrastructure devices that support them, and the networking switches and routers that manage connectivity. Across all these devices, we established a solid inventory framework to ensure that we could collect relevant data from our devices, including status, device details, capabilities, and requirements for connectivity to corporate resources. We used asset-inventory tools, device-configuration backups, and data pulled from live devices to collect and assemble our network device inventory. This data was critical for our reporting and dashboards so that we could track progress as we deployed new network-configuration standards, segments, and policies.

Cataloging and assessing devices

After we collected device data, we had to decide what to do with the devices. Identifying devices that were incompatible with Zero Trust networking policies, configurations, protocols, and management techniques was a high-priority task. While many devices contained modern networking capability, we identified a large device population that required special attention.

We had devices on our network that supported only basic networking capabilities. For example, the air-handling units for many of our buildings in the Puget Sound area connected to the network with a TCP/IP address, but they didn’t support Dynamic Host Configuration Protocol (DHCP) or remote configuration. Changing the units’ addresses meant traveling to the buildings, connecting a network cable to the unit, and accessing the management console by using a laptop. It was a simple task for one air handler, but a massive project to address the thousands of air handlers spread across an entire campus.

Simple devices like these air handlers would never support Zero Trust networking’s controls and configuration. Likewise, many devices across our network had similar issues. Replacing these devices wasn’t an option, so we needed to understand how to deal with them in place.

Zero trust networking is about security posture. How our devices connect to, authenticate to, and traverse the network is under our control and management from end to end.

—Sean Adams, lead engineer for wired infrastructure, Microsoft Digital

We also provided guidance for these devices and recommendations for eventual replacements. The guidance was essential to moving the network toward compliance. However, the bigger job was turning that guidance into governance to ensure that newly purchased devices and infrastructure supported our Zero Trust networking implementation requirements. As part of ongoing efforts to modernize our in-building experiences, we supply device guidance into our broader Digital Transformation initiative to ensure that new devices in the network ecosystem meet the basic requirements for Zero Trust compatibility.

Onsite connectivity

Zero Trust network connectivity needs to be inherently secure, flexible, and universal. To build effective connectivity across Microsoft, we aligned our security and segmentation strategies with Zero Trust model goals. We ensured that our connectivity methods could support and enforce the controls necessary for Zero Trust networking.

“Zero trust networking is about security posture. How our devices connect to, authenticate to, and traverse the network is under our control and management from end to end,” says Sean Adams, a lead engineer for wired infrastructure in MSD.

Establishing inherent security

Security is inherent in our Zero Trust networking design, from end to end. We designed our implementation to create secure experiences for devices and users across our entire network. We involved our security experts in design and recommendations from the beginning of the project. Risk and vulnerability assessments helped us determine prioritization for deployment.

Segmenting and connecting devices

Emphasis on network perimeter security and defense-in-depth concepts are no longer useful or relevant in a Zero Trust networking environment. Network segmentation assures limited lateral movement and is foundational to our Zero Trust strategy. We created our segmentation strategy to support the greatest level of network flexibility with the fewest number of segments. Segmentation provided absolute control over network access. We implemented our segmentation controls over six different segments: corporate network, internet, guest connectivity, isolated IoT, modern IoT, and infrastructure administration. We connected our users to the closest possible internet egress point to facilitate an internet first approach and provide the best performance and highest bandwidth. Our network environment was already virtualized, so we were able to implement segmentation with relative ease.

Implementing Zero Trust networking controls will disconnect incompatible devices from the network. In cases where simple IoT devices were present, as with the air handlers mentioned earlier, we moved them to the dedicated IoT segment to isolate those devices from the rest of the general network population but still allow them network connectivity.

Coming from a primarily flat corporate network meant a restructuring of standard connectivity. With segmentation, network ports were no longer linear. For wired devices, we dynamically assigned devices to segments based on port and geographic region. This gave us full control over the connection, right down to the individual port, and massive scalability across all regions.

While we have maintained our multi-protocol label switching (MPLS) network, we also maintain more than 250 carrier-dependent WAN circuits. Implementing consistent segmentation across these circuits required effective planning and testing. Testing carrier QoS measurement was important. In some instances, implementing segmentation across previously unsegmented circuits caused incorrect QoS calculations that directly affected available bandwidth.

Managing connectivity methods

Wired and wireless connectivity are both built on the same system of network segmentation and routing. The internet is our default network wherever possible. We operate most of our infrastructure in the cloud, and we get devices to an internet edge in as few hops as possible.

We’ve consolidated our wireless networks across our regions. We’re moving toward a single default service set identifier (SSID), combining our corporate and internet wireless networks into one network with a default internet posture and least-required privilege on the network. Through 802.1X and network policy, we can move devices into segments that provide corporate resource access. This makes network posture flexible, monitorable, and fully enforced across all connectivity methods.

Particularly in the current circumstance with the COVID-19 pandemic, it’s crucial that the majority of our workforce can perform their job duties without being onsite. We already had a robust remote access infrastructure for mobile workers and off-hours use, but we’ve augmented our services and scaled them up to support every user at all times.

—David Lef, principal IT enterprise architect, Microsoft Digital

Consistent segmentation and a consolidated wireless SSID provide several advantages for Zero Trust networking: the internet as the network of choice, wireless as the connectivity method of choice, and required proof of identity across all devices and segments. After a device connects to wireless, it’s easy to transparently move that device across segments and implement other Zero Trust networking controls.

Offsite and remote connectivity

Most of our workforce expects to be able to access the resources required to perform their duties when they’re not actually on-premises in a Microsoft building.

“Particularly in the current circumstance with the COVID-19 pandemic, it’s crucial that the majority of our workforce can perform their job duties without being onsite,” Lef says. “We already had a robust remote access infrastructure for mobile workers and off-hours use, but we’ve augmented our services and scaled them up to support every user at all times.”

The majority of our productivity resources are available through the internet and Microsoft public services. For those that remain on our private networks, two primary services are available today to provide seamless and secure client connectivity to our users:

• A virtual private network (VPN) infrastructure accessible by Microsoft employees and vendors with managed corporate devices and identities.
• A centralized Windows Virtual Desktop (WVD) service running in Microsoft Azure, which supplies a managed Windows 10 desktop experience to employees and vendors from devices that support the Remote Desktop Protocol RDP).

Investments in automation tooling and education are significant, but it would have been impossible to deploy Zero Trust networking at Microsoft without effective automation and a network as code approach.

—Sajith Balan, lead engineer for network routing and transport, Microsoft Digital

Deploying and automating functionality

We’ve deployed Zero Trust networking across our global network. Considerations for individual regions, business needs, and technical requirements all influenced deployment methods and cadence. Throughout the deployment landscape, we’ve integrated automation and configuration validation by default to ensure a consistent, repeatable, and scalable deployment experience.

“Investments in automation tooling and education are significant, but it would have been impossible to deploy Zero Trust networking at Microsoft without effective automation and a network as code approach,” says Sajith Balan, a lead engineer for network routing and transport in MSD.

Planning and deploying

We established the scope of our Zero Trust networking deployment early. This helped us develop design principles and set standards to ensure our designs remained consistent throughout the project. We based deployment priority primarily on business impact, technical requirements, and potential for vulnerability. Deploying to five devices was quicker and less complex than deploying to five hundred devices, so we deployed to smaller environments first.

We prioritized our infrastructure deployment over the user experience deployment to minimize disruption and ensure quick learning with the least impact. Decoupling these two elements allowed us to implement and test infrastructure early and address bugs and issues without the pressure of the user experience being affected by this process. When infrastructure was ready, we deployed the software components that brought Zero Trust networking to the user.

We optimized costs wherever it was relevant and effective. Zero Trust networking affected every device at Microsoft, and we didn’t have the scope or budget to replace every device.

Automating with network as code

Network as code, the concept that the definitive configuration for a network is defined by code in a centralized repository and not by the current state of a device, was critical to the overall implementation of Zero Trust networking and our ability to deploy at scale. Our network environment already had well-defined engineering standards, so we implemented network as code with relative ease. We used network as code to standardize our network’s configuration management and reduce configuration drift by using software development processes. One of network as code’s outcomes is the ability to reconstruct the network repeatedly from nothing more than a source code repository and bare-metal resources.

Network as code provided a source of truth across our environment. By modeling device configuration into structured data, we used network as code to store and catalog network device configuration data centrally and decouple it from the physical device. This supported more efficient management of configuration and created new scenarios for disaster recovery and rapid deployment. Without network as code, deployment at scale would have been impossible to accomplish at Microsoft. We also use network as code to validate the health of deployed services.

Deploying iteratively

Starting small and gradually deploying to a broader scope was our standard approach with Zero Trust networking. Using this ring-based approach helped us test deployment models on small groups before releasing functionality more broadly. Flighting with a small cohort helped us grow to larger deployments without fear of time-consuming rollbacks or sweeping changes to the configuration.

Incremental deployment made it easier to deploy to an actively used environment. Throughout the Zero Trust networking implementation, we worked with live networks that hosted users and business processes happening in real time. In situations where we couldn’t gather the appropriate data to guarantee success, the ability to deploy on a small scale helped us test, assess, and quickly refine our deployment approach. For example, when we deployed our new internet-first wireless network to shift the default client posture off the corporate intranet, we started with an individual floor in a building that contained active users. This initial deployment supplied quick feedback with little risk. From there, to minimize disruption, we gradually expanded to entire buildings and then multiple buildings per day.

Zero Trust networking shouldn’t impinge on an employee’s ability to use the network. We want the transition to Zero Trust to be as friction free as possible for our employees while ensuring secure and monitored infrastructure.

—Mark Bryan, lead engineer for wireless infrastructure, Microsoft Digital

Flighting and iteration also helped us identify solutions that wouldn’t work and find alternatives early in the deployment before too many users were affected. If we found that a solution only worked for 10 percent of the devices or users in a location or region, we knew that we had to reassess the solution and refactor to involve the broadest device population while still maintaining our standards.

Ensuring consistent user experiences

Our users are the consumers of our Zero Trust networking environment. For that reason, it’s critical that we continually examine their needs and how Zero Trust networking affects their experience. How users interact with the network affects their acceptance level for Zero Trust networking. Immature deployments and mismatched pilot groups create dissatisfaction that can lead to low adoption and acceptance rates. We focused on effectively monitoring and incorporating user feedback throughout implementation.

“Zero Trust networking shouldn’t impinge on an employee’s ability to use the network. We want the transition to Zero Trust to be as friction free as possible for our employees while ensuring secure and monitored infrastructure,” says Mark Bryan, a lead engineer for wireless infrastructure in MSD.

Educating users

Educating users and device owners on Zero Trust networking helped increase adoption and user satisfaction. Deployment of Zero Trust networking immediately identified incompatible devices. If a device didn’t support the controls in place, the device was disconnected from the network. Informing end users of these behaviors was critical to smooth deployment. For example, if we planned to enforce authentication on a network where it hadn’t been enforced before, we could initially enable the authentication method in a silent/soft mode and identify which devices weren’t successfully authenticating. Owners of those devices were notified so that they could adapt their configurations to meet requirements or make plans to move to a more suitable network type.

Working with users and deployment regions

Through our data analysis and pilot testing, we encountered a diverse set of business and technical needs across our global network environment. Each region or location had specific technical capabilities and considerations. Device availability, telecom capabilities, data-residency regulations, and many other regional considerations contributed to how we approached, designed, and implemented Zero Trust networking for each location.

Monitoring the user experience

We had to understand the use cases and the personas on our network. Deploying Zero Trust networking wasn’t typically disruptive. However, many systems that developers and software engineers used were designed for the corporate network and didn’t scale well to a Zero Trust networking environment. In these areas, we considered test groups and early adoption carefully. These users were potential Zero Trust networking advocates, especially in situations where implementation could have been disruptive. We monitored user experience with data insights and Microsoft Power BI to gather actionable data and modify our implementation approach accordingly.

Zero Trust networking provides a model that effectively adapts to the complexity of and constant change within the corporate environment. It supports the mobile workforce and protects people, devices, apps, and data regardless of location. In sharing the lessons that we’ve learned so far, we hope to help other enterprises to adopt Zero Trust networking effectively and efficiently. As we continue to deploy the Zero Trust model across the Microsoft enterprise, we’re learning from our experience and adapting our approach to achieve our goals.

Stay tuned for more articles and case studies that provide additional details about our Zero Trust network implementation.

• Check out Microsoft’s digital security team answers your Top 10 questions on Zero Trust.
• Discover using a Zero Trust strategy to secure Microsoft’s network during remote work.
• Read more about Running on VPN: How Microsoft is keeping its remote workforce connected.

The post Learning from engineering Zero Trust networking at Microsoft appeared first on Inside Track Blog.

In many enterprises, network security has traditionally focused on strictly secured and monitored corporate network perimeters. Today, in a mobile-first and cloud-first world, business network traffic exists outside the corporate network as much as it does within. The rate and the sophistication level of security attacks are increasing. Organizations can no longer rely on the traditional model of simply protecting their remaining internal environments behind a firewall. Adopting a Zero Trust strategy can help to ensure optimal security without compromising end users’ experiences.

Our team in Microsoft Digital (MSD) is deploying Zero Trust networking across the enterprise to support the Zero Trust model that our internal security team is implementing across Microsoft.

The Zero Trust model centers on strong identity, least-privilege access, device health verification, and service level control and telemetry across the entire IT infrastructure. The network perimeter is no longer the primary method of defense for an enterprise.

At Microsoft’s scale, with more than 600 sites in 120 countries and regions, evolving our network strategy to embrace Zero Trust networking has required alignment across the entire organization.

[Gain insight from Microsoft’s digital security team on Top 10 questions for Zero Trust. | Read more about sharing how Microsoft protects against ransomware. | Unpack the lessons learned in engineering Zero Trust networking.]

Sharing leadership lessons

Throughout our journey toward Zero Trust networking, we’ve learned valuable lessons. We’ve experienced challenges in the various stages of implementation that forced us to reassess and adjust our tactics and methods. We hope that by sharing our experiences we can help other enterprises better prepare to adopt and implement a Zero Trust networking strategy and overcome similar obstacles.

To read more about the lessons that our engineers have learned from our Zero Trust networking deployment, visit Lessons learned in engineering Zero Trust networking.

Planning and design

Plan using a broad scope

The impact of implementing Zero Trust networking is significant because of its size and scope. At Microsoft, early and big-picture planning involved all relevant stakeholders, including network teams, security teams, user experience teams, team managers, infrastructure service providers, and compliance auditors. We started with a comprehensive plan and worked toward more specific plans and goals.

Establish goals

We established several primary goals that we used as targets for the implementation process. While each of these considerations involved a finite subset of goals and discrete features that informed the specifics of Zero Trust networking implementation, they also served as high-level signposts to provide the direction that best supported our business. Our primary goals included:

• Understand the environment and architecture. Zero Trust networking involved fundamental changes to our network and how our business used it. We needed to understand our existing infrastructure on several different levels: what equipment was in the field, how our network was supporting critical business processes, and what network aspects we must change to support Zero Trust networking properly. This included understanding wired and wireless user-experience scenarios, evaluating traffic patterns, and measuring inbound and outbound capacity utilization. Investing in data insights and visualizations was critical to measuring current usage and modeling future usage.
• Be deliberate about implementation scope. We established scope early. We set all corporate-managed user wired and wireless networks in scope for Zero Trust networking but left dedicated engineering and services environments, like labs and datacenters, out of scope. A well-defined scope set firm boundaries for implementation tasks that followed. If our engineers could examine our scope documentation and observe that a specific device class was out of scope, they could identify that equipment easily when they encountered it in the field during implementation. Technical and fiscal limitations also directly affected the scope. If we couldn’t replace 50,000 simple IP devices in a location or region because of cost or replacement availability, we knew that those devices must be isolated from the network and addressed when a replacement was viable.
• Establish staffing and knowledge base requirements. There were many aspects of Zero Trust networking that required specific knowledge, including network security expertise, firewall and policy management, network telemetry, and foundational knowledge of traditional network functions. In addition, we identified opportunities for more in-depth automation of network configuration and deployment activity to reduce workload for our engineers and reduce the need for staffing increases.
• Embrace the internet as transport. A Zero Trust Networking implementation shifts to the internet as the default network of choice to get users and systems to their dominant cloud workloads. At Microsoft, we had been dependent on a traditional, flat corporate network model for decades. Embracing the internet meant rethinking and restructuring our network to best support the Zero Trust model. Internet-first thinking informed our decision making in all implementation areas, including perimeter security, segmentation and routing, device selection, security and policy standards, and user experience.

Teams and organization

Leadership engagement

Across any large organization, individual lines of business and departments have varying requirements. We involved leadership at all levels in Microsoft to create transparency, collect information, and gain allies and sponsors for implementing a Zero Trust network. Because we‘re also asking our customers to trust us with their critical data and workloads, our cloud offerings and services also must reflect—and support—Zero Trust principles.

We engaged executive leadership and obtained sponsorship as early in the process as possible. Visible leadership support helped drive the project forward. Effective sponsorship helped our teams overcome priority conflicts and other cultural and operational obstacles.

Governance and responsibilities

In partnership with our security team, we established governance to bring our leadership together. We addressed roles and responsibilities across teams, ensuring that we documented them. We established intake prioritization standards to ensure that our implementation teams worked on the most important tasks from a business perspective. To set these standards, we examined the business impact and implementation effort for new tasks as they arose by using an agile framework.

Planning and implementation teams

We required a broad range of business and technical knowledge across planning and implementation teams. We needed security experts that could reevaluate our network policies and standards across the implementation. We included network experts from various areas, including wired and wireless networks, virtualization and network segmentation, traffic management, quality of service (QoS), and device configuration. Understanding the potential impact on existing network team members was also important. Fortunately, we had already added software engineering expertise to our network engineering teams to drive automation, and Zero Trust accelerated that. We ensured that we placed our experts in planning and decision-making roles, thereby making the best use of our internal intellectual property. Finally, we directed as much of our high-effort, low-impact tasks, including physical infrastructure installation and maintenance, to outsourced providers.

Meetings and communication

Meeting cadence and scope

We based our meetings and communications strategy on agile methodology, a collaborative effort of self-organizing and cross-functional teams that could plan and iterate rapidly. Our core teams met briefly and often, while meetings including stakeholders and executive leadership occurred less frequently. We applied governance for how our teams worked together: how often we met, roles and responsibilities, and how we prioritized incoming work and changes to our plans. The following list reflects our meeting structure and frequency:

• Several times a week
  • Conduct brief stand-up meetings with our security, end-user experience, and business teams
  • Track feature progress
  • Track potential blockers
  • Assess overall project health
• Biweekly
  • Meet with stakeholders to provide progress updates in specific areas
• Monthly
  • Meet with steering committee, sponsors, and use-case scenario owners
• Quarterly
  • Meet with executive leadership to check alignment with business goals and plan for the future
  • Secure budget in time for fiscal planning to ensure that we could fund upcoming tasks
  • Align resource allocation for upcoming tasks

Measurement and assessment

We created and relied on process-monitoring systems and reporting dashboards to keep all team members informed on project status. We used Microsoft Power BI to build dashboards for teams at all levels, ensuring that each team, leader, stakeholder, or sponsor had an active overview of their relevant area. A partial list of useful dashboards included:

• Device inventory, to identify our install base, OS versions, and whether they could accept our new network policies and configuration standards.
• Configuration change tracking, to understand where we were on our Zero Trust journey, which devices were successfully onboarded, and which devices remained on legacy configurations.
• Usage monitoring, to understand our application patterns and help answer questions such as “Which applications still require VPN, and does each application have a roadmap to cloud adoption?”
• Internet of Things (IoT) inventory and network usage, to identify vulnerable devices such as conferencing kiosks, building-management systems, and life-safety systems. These are typically a primary focus area in a Zero Trust framework.

Deployment and execution

User experience assessment

User experience is one of our primary measures for organizational effectiveness across all Microsoft systems. Our users work in diverse locations, regions, and cultures, and a potentially different experience characterizes each location. Reaching out to our users and measuring experience and impact throughout the Zero Trust networking implementation helped us understand and avoid potential issues.

Situational dependencies, such as data-residency laws or telecom-systems capabilities, required us to change implementation plans. It was important to identify these dependencies and anomalies as early as possible in our deployment processes so that we could plan and adapt accordingly.

At Microsoft, a significant portion of our network workloads come from engineering teams with unique user experiences. Software and hardware engineers who build and test software and hardware systems have very different network usage profiles than typical information workers. We reached out early and often to this community to understand their current and future needs and account for them in our deployment flight planning.

Involvement of local support and users

Local IT and leadership teams were also instrumental in implementing Zero Trust networking across Microsoft. We relied heavily on local IT staff to supply information about their environment and ensure that our solutions accounted for local functionality limitations and technical considerations. These included network resources inventory, applications, and services required for productivity, and the impact of network traffic and topology changes.

Staff members’ input reduced the engineering workload and increased the overall knowledge base that our engineers had when designing each regional implementation. We used our local and regional teams’ capabilities to collect and supply information. Local staff—including technical, support, and leadership teams in each location—who were informed about and included in the planning and design process helped prevent surprise obstacles. These individuals also served as valuable advocates and advisors when we deployed Zero Trust networking; when our deployment reached their building or region, we had local support to ensure a smooth transition.

Zero Trust networking supports a model that effectively adapts to the complexity of the modern corporate environment. It supports the mobile workforce and protects people, devices, apps, and data regardless of location. In sharing the lessons that we’ve learned so far, we hope to help other enterprises adopt Zero Trust networking effectively and efficiently. As we continue to deploy the Zero Trust model across the Microsoft enterprise, we’re learning from our experience and adapting our approach to achieve our goals.

• Gain insight from Microsoft’s digital security team on Top 10 questions for Zero Trust.
• Read more about sharing how Microsoft protects against ransomware.
• Unpack the lessons learned in engineering Zero Trust networking.

The post Sharing Microsoft’s Zero Trust networking lessons for leaders appeared first on Inside Track Blog.

Managing identities and network access at Microsoft encompasses all the processes and tools used throughout the identity life cycle for employees, supplier staff, and partners. As a cloud-first company, our Microsoft Digital Employee Experience (MDEE) team uses features in the Microsoft Enterprise Mobility + Security suite, powered by Microsoft Azure, along with on-premises identity and access management solutions to enable our users to be securely productive, from anywhere.

We’re on a multi-year journey of transforming into a cloud-first, mobile-first enterprise. Though we operate in a hybrid cloud environment today, we’re moving on-premises identity technologies to the cloud, giving our employees flexibility they need. Plus, application owners can use the power of Microsoft Graph to effectively manage access to applications and resources.

[See how we’re implementing strong user authentication with Windows Hello for Business. Learn more about verifying identity in a Zero Trust model internally at Microsoft. Unpack implementing a Zero Trust security model at Microsoft.]

Unifying the environment

To enable a single user identity for authentication and offer a unified experience, we integrated on-premises Windows Server Active Directory forests with Microsoft Azure Active Directory (Azure AD). Our geographically distributed Active Directory environment uses Windows Server 2016. We use Azure AD Connect and Active Directory Federation Services (AD FS) when an Azure-based application needs user attributes—for example, their location, organization, or job title. User information is available if the service has the right permissions to query for those attributes.

As shown in the image below, our identity and access environment is hybrid, federated, and cloud-synced.

The Microsoft identity environment includes:

• 131,300 employees
• 303,000 global identities
• 488,000 partner identities
• 10,400 privileged identities that have some level of elevated access
• 15 million authentication requests per month
• 1.6 million cloud applications—99 percent of our apps—using Azure Active Directory (Azure AD)
• 3,000 applications using Active Directory Federation Services (AD FS)

Microsoft Azure Active Directory Connect

Microsoft Azure Active Directory Connect integrates on-premises directories with Microsoft Azure Active Directory. It gives users a single identity in Office 365, Azure, and software as a service (SaaS) applications that are integrated with Azure AD. Azure AD Connect consists of three main components:

• Synchronization services. Microsoft Azure AD Connect sync services creates users, groups, and other objects. It makes sure that the on-premises identity for users and groups matches the cloud identity.
• AD Federation Services. Federation is an optional part of Microsoft Azure AD Connect that’s used to configure hybrid environments using an on-premises AD FS infrastructure. It supports single sign-on and enforces Active Directory sign-on policy with smart card or third-party, multifactor authentication.
• Health Monitoring. Microsoft Azure AD Connect Health offers a central location in the Microsoft Azure portal to monitor system health.

Enabling identity models in Microsoft 365

Microsoft 365 supports three identity models that support a variety of identity scenarios. Depending on how you manage identities, you can use a cloud identity model, federated identity model, or the synchronized identity model.

We use the federated model where we synchronize on-premises directory objects with Microsoft 365 and manage our users on-premises. The users have the same password on-premises and in the cloud, and they do not have to sign in again to use Microsoft 365. The user password is verified by AD FS—the password hash doesn’t need to be synchronized to Microsoft Azure AD, and the user doesn’t have to sign in again to use Microsoft 365.

Enabling users

Every employee, supplier staff, or partner that needs access to the corporate network receives an email address to sign in to their primary account. That primary account is synced to Microsoft Azure AD and gives the user access to corporate resources, Microsoft 365, Microsoft SaaS, and corporate business unit and third-party SaaS and platform as a service (PaaS) applications (such as apps for expenses or travel).

Strong authentication

We require multifactor authentication to verify a user’s identity before giving them access to corporate resources when they’re not connected to the corporate network. People use multifactor authentication in a few ways, including certificate-backed virtual and physical smart cards, Windows Hello for Business with PIN or biometric sign in, and Microsoft Azure Multi-Factor Authentication (MFA) that uses a phone or the Microsoft Authenticator app. On domain-joined devices that we manage, multifactor authentication has become almost transparent to users.

Currently, the use rate for each authentication method is approximately:

• Certificate-based using virtual or physical smart cards—21 percent.
• Windows Hello for Business—25 percent.
• Microsoft Azure MFA using phone authentication or an authenticator app—54 percent.

Certificate-based

For many years, certificated-based physical and virtual smart cards were the main method of multifactor authentication. As the other options have been enabled, smart card use has been declining.

Windows Hello for Business

With the deployment of Windows 10 and Windows 11, we enabled Windows Hello for Business, which can replace passwords with strong two-factor authentication that combines an enrolled device with a PIN or biometric (fingerprint or facial recognition) to sign in. Windows Hello was easily implemented within our existing identity infrastructure, by extending certificates to include the use of a PIN or biometrics as an enterprise credential; plus, it allows remote access. Users can sign in to their Microsoft account, an Active Directory account, or an Azure AD Premium account.

Microsoft Azure MFA

Although Windows Hello has become the preferred method for our Windows 10 and Windows 11 domain-joined devices, we support access using mobile platforms such as iOS and Android. Microsoft Azure MFA is the best solution for securing our users and data on these platforms, and it integrates seamlessly with our existing AD FS infrastructure.

Enabling partner access

For Microsoft partners, we’ve started using Microsoft Azure Active Directory business-to-business (B2B) collaboration. Microsoft Azure AD B2B collaboration make it easier to enable single sign-on access to Microsoft extranet applications and collaboration spaces.

Invitation lists are created using manually exported lists in the form of comma-separated value (.csv) files. We’re working on automating the process to reduce the potential for error and increase our speed.

Enabling mobile access

As a cloud-first company, many of our corporate resources are in the cloud. People can use multifactor authentication to securely access their work from anywhere. To enable mobile access to on-premises resources, we use a couple of remote access solutions:

• We help ensure the security of cloud resources and remote access at Microsoft by validating who the user is through multifactor authentication.
• We check system health to ensure that the user accesses corporate resources on a device that’s managed through System Center Configuration Manager or Microsoft Intune, and that the device has all the latest updates installed.

We introduced Conditional Access in a Windows 10 update and are continuing its use with Windows 11. To help ensure that users sign in from a healthy device with strong authentication, we also configure device management policies for remote access.

Role and user attribute access roles

We’ve started to implement role-based and user attribute–based access. We created a couple of dynamic groups that set up parameters for variable access to resources based on device, location, and type of user. We’ve focused on large user categories—such as employees and supplier staff—but we’re working on adding more specific roles.

Self-service

Cloud services gave us the ability to introduce more self-service capabilities for identity and access management. These services have helped reduce manual administrative tasks and Helpdesk support calls for help with password and identity management changes.

• Password management. Microsoft employees can change their passwords using an internal, cloud-based, self-service password management solution. We integrated Azure MFA, including verification with a phone call or mobile app, as part of the process. Users are prompted to answer verification questions when they change a password. When users need to change their password, they do so without calling Helpdesk.
• Security and distribution group management. Tools like Microsoft 365 Teams help users manage their teams without going through an administrator or Helpdesk to create and manage their groups. Group owners can set up access policies to user groups rather than individual.
• Microsoft Azure AD Join. At Microsoft, we support bring your own device (BYOB) scenarios; many employees do part of their work on their personal device. In Windows 10 and now in Windows 11, our users can add an Azure AD account, and their device will be enrolled in mobile device management through Microsoft Intune.

Managing the service

To manage on-premises and cloud identity services and enable day-one productivity for new users, we use established processes for provisioning and deprovisioning user identities, and to monitor and audit account usage.

User account life cycle management

User account life cycle management includes all processes for provisioning and deprovisioning user identities for both full‑time employees (FTEs) and supplier staff. New identities are created in our accounts provisioning system and in Active Directory. After an account is created, user sync enables it in Microsoft Azure AD. Account provisioning is the same for both FTE and supplier staff identities, but they are granted different levels of access. For example, by default, FTEs are granted remote access, but it’s granted for supplier staff only upon manager approval.

Provisioning

To provision an active user account:

1. A business manager or Human Resources employee submits a provisioning request, which includes information such as the legal name of the user, the domain, their physical location, and if they have an office number or are a mobile worker.
2. After the request is submitted, the data is consumed by SAP, which generates a unique employee ID number for each person. New employee data automatically goes through the SAP web service to the accounts provisioning service.
3. The accounts service receives the employee ID from the SAP web service, with an action to provision the user account. We create the user identity, alias, and a temporary password. We also create the mailbox where the mailbox object is stamped in Active Directory.
4. The user employee ID number and provisioned alias are provided as a key pair back to the SAP web service.
   • SAP publishes the data through an HC01 feed, which gives the user identity access to Human Resources productivity sites, including finance and benefits.
   • In parallel, the accounts service sends account details (alias, temporary password, and mailbox) to the manager, sponsors, and other designated recipients identified in the original provisioning request.

Deprovisioning

When we receive a deprovisioning request from a business manager or Human Resources, we terminate and disable the user account from corporate access, including alternate and elevated access credentials. We reset the user’s network password and disable remote access, Office Web Access, and Skype for Business.

Automating our processes

For the past several years, we’ve automated our core service scenarios to help ensure an active user account is provisioned before an employee’s start date, so employees will be productive on their first day. This includes provisioning scenarios for new hires, rehires, new supplier staff, and supplier staff to FTE conversions. We plan to automate additional post-provisioning activities, such as renaming aliases, domain moves, and remote access requests. We also plan to migrate the service to a third-party platform that will provide increased efficiency, integration, and provide more identity-related self-service capabilities.

Auditing and monitoring

Auditing identities is like other services—we collect event types in our central log management system. For monitoring identity events, we coordinate with the engineering team to define use cases and the monitoring conditions that would alert us. Those correlated conditions could come from any of the different monitoring pipelines, including Microsoft Cloud App Security.

Network monitors and endpoint monitoring, like Windows Defender Advanced Threat Protection (ATP), feed in to our security and information event management (SIEM) solution. When we get an alert, the service operations team determines whether the alert is valid and if it needs to be opened for investigation. If we determine that it’s a real alert, we use the information in the SIEM and in the Defender ATP console to begin investigating. Depending on the severity of the alert, it could be escalated to the incident response team, the legal department, or even law enforcement.

To help us deal with the number of alerts, we use a third-party behavioral analytics tool that helps reduce event noise and helps us better identify real events.

Cloud-enabled protection

Our traditional approach was to protect all the assets on the corporate network. Because we’ve moved most of our assets to the cloud, we now focus on security at the user level. We do that by introducing better user and admin accountability with security and governance, including:

• Controlling access to resources.
• Requiring strong user authentication.
• Responding to advanced threats by monitoring for specific risk-based scenarios.
• Mitigating administrative risks.
• Governance of on-premises and cloud identities.

Using privileged identities to manage elevated access

Privileged identity management is an important part of a larger effort within Microsoft Digital to secure high-value corporate assets. Of the roughly 303,000 identities that we manage, approximately 10,000 on‑premises and 400 Microsoft Azure AD users need elevated access to data and services. We have other tools and a process for the subset of users that have administrative—or elevated—access to data and services at Microsoft.

One important way we protect elevated access accounts is through just in time (JIT) access. Rather than have separate credentials or a persistent admin session, JIT elevates access for a specific duration. Access expires at the end of that time.

We also protect elevated accounts by requiring on-premises admins to sign in on secure access workstations, and we plan to expand that requirement to cloud admins.

As our identity and access management solution has evolved, we’ve discovered a few best practices, including:

• If your Human Resources systems are primarily on-premises, you can use a hybrid approach to create user identities in Active Directory and sync them to the cloud.
• Assess your environment honestly to determine how to best use the cloud to reduce complexity for on-premises process points. Migrating to the cloud offers an opportunity to reassess existing processes and identify ways that the cloud can make your identity infrastructure more efficient. The scalability of Azure solutions offer advantages that can help modernize processes and technology dependencies.
• Identity is the new security perimeter. Azure provide the ability through it’s security products to help protect those identities much more effectively than traditional network/datacenter monitoring.

As for our future, we’re exploring other changes to identity management, including eliminating time-bound password expiration by moving to a system where passwords stop working only when triggered by specific risks or user behaviors.

Beyond that, we look forward to a future where our identities are in the cloud and there are no passwords. Within the next few years, we hope to move to a purely cloud-based service model, rather than our current, cloud-enabled state. Windows Hello for Business was our first step toward a future where biometrics replace passwords.

Also, we’re deploying Azure Information Protection at Microsoft. Azure Information Protection integrates with cloud identities to help protect corporate data. We continually look for ways that we can be more efficient as we move to cloud-only solutions for identity and access management.

• See how we’re implementing strong user authentication with Windows Hello for Business.
• Learn more about verifying identity in a Zero Trust model internally at Microsoft.
•  Unpack implementing a Zero Trust security model at Microsoft.

Please share your feedback with us—take our survey and let us know what kind of content is most useful to you.

The post Managing user identities and secure access at Microsoft appeared first on Inside Track Blog.