![\"Microsoft](\"https:\/\/www.microsoft.com\/insidetrack\/blog\/uploads\/prod\/2021\/10\/ms-digital-technical-stories-300x112.png\")
Our Microsoft Digital (MSD) team is deploying Zero Trust networking internally at Microsoft as part of our Zero Trust initiative, our comprehensive approach to verification and identity management.<\/p>\nOur Microsoft Digital (MSD) team is deploying Zero Trust networking internally at Microsoft as part of our Zero Trust initiative, our comprehensive approach to verification and identity management.<\/p>\n
Powered by Microsoft\u2019s 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.<\/p>\n Zero Trust networking is a journey; we\u2019ve come a long way, and we\u2019ve 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.<\/p>\n [To read more about the leadership lessons from our Zero Trust networking deployment, visit Zero Trust networking: Sharing lessons for leaders<\/a>. | Check out Microsoft\u2019s digital security team answers your Top 10 questions on Zero Trust.<\/a> | Discover using a Zero Trust strategy to secure Microsoft\u2019s network during remote work.<\/a> | Read more about Running on VPN: How Microsoft is keeping its remote workforce connected.<\/a>]<\/em><\/em><\/p>\n 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.<\/p>\n These goals directly influenced our implementation and molded our approach to specific inventory, design, deployment, and monitoring efforts throughout Zero Trust Networking.<\/p>\n For something as critical as a Zero Trust networking implementation, we needed to use our own network and security experts; we couldn\u2019t outsource that intellectual property. We allocated these resources early and dedicated our best and brightest minds to critical decisions and tasks.<\/p>\n Zero Trust networking requires a reassessment of any organization\u2019s network operations. At Microsoft, we\u2019re making fundamental changes to a network that hosts more than 1 million devices.<\/p>\n \u2014David Lef, principal IT enterprise architect, Microsoft Digital<\/p>\n<\/blockquote>\n Although high-level goals established at the leadership level drove the entire Zero Trust implementation, we didn\u2019t 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.<\/p>\n 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.<\/p>\n \u201cZero Trust networking requires a reassessment of any organization\u2019s network operations. At Microsoft, we\u2019re making fundamental changes to a network that hosts more than 1 million devices,\u201d says David Lef, a principal IT enterprise architect in MSD.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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\u2019t support Dynamic Host Configuration Protocol (DHCP) or remote configuration. Changing the units\u2019 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.<\/p>\n Simple devices like these air handlers would never support Zero Trust networking\u2019s controls and configuration. Likewise, many devices across our network had similar issues. Replacing these devices wasn\u2019t an option, so we needed to understand how to deal with them in place.<\/p>\n 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.<\/p>\n \u2014Sean Adams, lead engineer for wired infrastructure, Microsoft Digital<\/p>\n<\/blockquote>\n 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.<\/p>\n 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.<\/p>\n \u201cZero 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,\u201d says Sean Adams, a lead engineer for wired infrastructure in MSD.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n We\u2019ve consolidated our wireless networks across our regions. We\u2019re 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.<\/p>\n Particularly in the current circumstance with the COVID-19 pandemic, it\u2019s 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\u2019ve augmented our services and scaled them up to support every user at all times.<\/p>\n \u2014David Lef, principal IT enterprise architect, Microsoft Digital<\/p>\n<\/blockquote>\n 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\u2019s easy to transparently move that device across segments and implement other Zero Trust networking controls.<\/p>\n Most of our workforce expects to be able to access the resources required to perform their duties when they\u2019re not actually on-premises in a Microsoft building.<\/p>\n \u201cParticularly in the current circumstance with the COVID-19 pandemic, it\u2019s crucial that the majority of our workforce can perform their job duties without being onsite,\u201d Lef says. \u201cWe already had a robust remote access infrastructure for mobile workers and off-hours use, but we\u2019ve augmented our services and scaled them up to support every user at all times.\u201d<\/p>\n 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:<\/p>\n 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.<\/p>\n \u2014Sajith Balan, lead engineer for network routing and transport, Microsoft Digital<\/p>\n<\/blockquote>\n We\u2019ve 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\u2019ve integrated automation and configuration validation by default to ensure a consistent, repeatable, and scalable deployment experience.<\/p>\n \u201cInvestments 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,\u201d says Sajith Balan, a lead engineer for network routing and transport in MSD.<\/p>\n 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.<\/p>\n 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.<\/p>\n We optimized costs wherever it was relevant and effective. Zero Trust networking affected every device at Microsoft, and we didn\u2019t have the scope or budget to replace every device.<\/p>\n 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\u2019s configuration management and reduce configuration drift by using software development processes. One of network as code\u2019s outcomes is the ability to reconstruct the network repeatedly from nothing more than a source code repository and bare-metal resources.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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\u2019t 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.<\/p>\n Zero Trust networking shouldn\u2019t impinge on an employee\u2019s 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.<\/p>\n \u2014Mark Bryan, lead engineer for wireless infrastructure, Microsoft Digital<\/p>\n<\/blockquote>\n Flighting and iteration also helped us identify solutions that wouldn\u2019t 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.<\/p>\n Our users are the consumers of our Zero Trust networking environment. For that reason, it\u2019s 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.<\/p>\n \u201cZero Trust networking shouldn\u2019t impinge on an employee\u2019s 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,\u201d says Mark Bryan, a lead engineer for wireless infrastructure in MSD.<\/p>\n 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\u2019t 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Stay tuned for more articles and case studies that provide additional details about our Zero Trust network implementation.<\/p>\n Our Microsoft Digital (MSD) team is deploying Zero Trust networking internally at Microsoft as part of our Zero Trust initiative, our comprehensive approach to verification and identity management. Powered by Microsoft\u2019s 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 […]<\/p>\n","protected":false},"author":133,"featured_media":8937,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"_hide_featured_on_single":false,"_show_featured_caption_on_single":true,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[1],"tags":[423,407,239],"coauthors":[646],"class_list":["post-8934","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-developer-tools","tag-enterprise-mobility-and-security","tag-network","program-microsoft-digital-technical-stories","m-blog-post"],"jetpack_publicize_connections":[],"yoast_head":"\n![\"Graphic](\"https:\/\/www.microsoft.com\/insidetrack\/blog\/uploads\/prod\/2022\/11\/10138_image001.jpg\")
Primary goals<\/h2>\n
\n
Implementation considerations<\/h2>\n
Understanding the environment<\/h3>\n
Creating a framework for network inventory<\/h4>\n
Cataloging and assessing devices<\/h4>\n
Onsite connectivity<\/h3>\n
Establishing inherent security<\/h4>\n
Segmenting and connecting devices<\/h4>\n
Managing connectivity methods<\/h4>\n
Offsite and remote connectivity<\/h3>\n
\n
Deploying and automating functionality<\/h3>\n
Planning and deploying<\/h4>\n
Automating with network as code<\/h4>\n
Deploying iteratively<\/h4>\n
Ensuring consistent user experiences<\/h3>\n
Educating users<\/h4>\n
Working with users and deployment regions<\/h4>\n
Monitoring the user experience<\/h4>\n
![\"Key](\"https:\/\/www.microsoft.com\/insidetrack\/blog\/uploads\/prod\/2021\/10\/key-takeaways-300x74.png\")
<\/p>\n![\"Related](\"https:\/\/www.microsoft.com\/insidetrack\/blog\/uploads\/prod\/2021\/10\/related_links-300x81.png\")
<\/p>\n\n