When Microsoft announced its plan to build an underwater datacenter, Lathish Kumar Chaparala was excited.

“During the initial rollout of Project Natick, I used to log on to their website and watch the live feed of the underwater camera that was mounted on the datacenter,” says Chaparala, a senior program manager on the networking team in Microsoft Digital, the engineering organization at Microsoft that builds and manages the products, processes, and services that Microsoft runs on.

Little did he know that he and his team would later be brought in to extend the network connectivity of this underwater datacenter so it could be safely fished out of the sea.

But the story begins much earlier than that.

We saw the potential benefit [of developing an underwater datacenter] to the industry and Microsoft. People responded to our work as if we were going to the moon. In our eyes, we were just fulfilling our charter—taking on challenging problems and coming up with solutions.

– Mike Shepperd, senior research and development engineer on the Microsoft Research team

The idea of an underwater datacenter came out of ThinkWeek, a Microsoft event where employees shared out-of-the-box ideas that they thought the company should pursue. One creative idea was put forth by employees Sean James and Todd Rawlings, who proposed building an underwater datacenter powered by renewable ocean energy that would provide super-fast cloud services to crowded coastal populations.

Their idea appealed to Norm Whitaker, who led special projects for Microsoft Research at the time.

Out of this, Project Natick was born.

“Norm’s team was responsible for making the impossible possible, so he started exploring the viability of an underwater datacenter that could be powered by renewable energy,” says Mike Shepperd, a senior research and development engineer on the Microsoft Research team who was brought on to support research on the feasibility of underwater datacenters.

It quickly became a Microsoft-wide effort that spanned engineering, research, and IT.

“We saw the potential benefit to the industry and Microsoft,” Shepperd says. “People responded to our work as if we were going to the moon. In our eyes, we were just fulfilling our charter—taking on challenging problems and coming up with solutions.”

Researchers on the project hypothesized that having a sealed container on the ocean floor with a low-humidity nitrogen environment and cold, stable temperatures would better protect the servers and increase reliability.

“Once you’re down 20 to 30 meters into the water, you’re out of the weather,” Shepperd says. “You could have a hurricane raging above you, and an underwater datacenter will be none the wiser.”

[Read about how Microsoft is reducing its carbon footprint by tracking its internal Microsoft Azure usage. Find out how Microsoft Digital is using a modern network infrastructure to drive transformation at Microsoft.]

Internal engineering team steps up

The Project Natick team partnered with networking and security teams in Microsoft Digital and Arista to create a secure wide-area network (WAN) connection from the underwater datacenter to the corporate network.

“We needed the connectivity that they provided to finish off our project in the right way,” Shepperd says. “We also needed that connectivity to support the actual decommissioning process, which was very challenging because we had deployed the datacenter in such a remote location.”

In the spring of 2018, they deployed a fully connected and secure datacenter 117 feet below sea level in the Orkney Islands, just off the coast of Scotland. After it was designed, set up, and gently lowered onto the seabed, the goal was to leave it untouched for two years. Chakri Thammineni, a network engineer in Microsoft Digital, supported these efforts.

“Project Natick was my first engagement after I joined Microsoft, and it was a great opportunity to collaborate with many folks to come up with a network solution,” Thammineni says.

Earlier this year, the experiment concluded without interruption. And yes, the team learned that placing a datacenter underwater is indeed a more sustainable and efficient way to bring the cloud to coastal areas, providing better datacenter responsiveness.

With the experiment ending, the team needed to recover the datacenter so it could analyze all the data collected during its time underwater.

That’s where Microsoft’s internal engineering teams came in.

“To make sure we didn’t lose any data, we needed to keep the datacenter connected to Microsoft’s corporate network during our extraction,” Shepperd says. “We accomplished this with a leased line dedicated to our use, one that we used to connect the datacenter with our Microsoft facility in London.”

The extraction also had to be timed just right for the same reasons.

“The seas in Orkney throw up waves that can be as much as 9 to 10 meters high for most of the year,” he says. “The team chose this location because of the extreme conditions, reasoning it was a good place to demonstrate the ability to deploy Natick datacenters just about anywhere.”

And then, like it has for so many other projects, COVID-19 forced the team to change its plans. In the process of coming up with a new datacenter recovery plan, the team realized that the corporate connectivity was being shut down at the end of May 2020 and couldn’t be extended.

“Ordering the gear would’ve taken two to three months, and we were on a much shorter timeline,” Chaparala says.

Shepperd called on the team in Platform Engineering, a division of Microsoft Digital, to quickly remodel the corporate connectivity from the Microsoft London facility to the Natick shore area, all while ensuring that the connection was secured.

The mission?

Ensure that servers were online until the datacenter could be retrieved from the water, all without additional hardware.

“My role was to make sure I understood the criticality of the request in terms of timeline, and to pull in the teams and expertise needed to keep the datacenter online until it was safely pulled out of the water,” Chaparala says.

The stakes were high, especially with the research that was on the line.

“If we lost connectivity and shut down the datacenter, it could have compromised the viability of the research we had done up until that point,” Shepperd says.

A seamless collaboration across Microsoft Research and IT

To solve this problem, the teams in Core Platform Engineering and Microsoft Research had to align their vision and workflows.

“Teams in IT might plan their work out for months or years in advance,” Shepperd says. “Our research is on a different timeline because we don’t know where technology will take us, so we needed to work together, and fast.”

Because they couldn’t bring any hardware to the datacenter site, Chaparala, Thammineni, and the Microsoft Research team needed to come up with a network redesign. This led to the implementation of software-based encryption using a virtual network operating system on Windows virtual machines.

It’s exciting to play a role in bringing the right engineers and program managers together for a common goal, especially so quickly. Once we had the right team, we knew there was nothing we couldn’t handle.

– Chakri Thammineni, a network engineer in Microsoft Digital

With this solution in tow, the team could extend the network connectivity from the Microsoft Docklands facility in London to the Natick datacenter off the coast of Scotland.

“Chakri and Lathish have consistently engaged with us to fill the gaps between what our research team knew and what these networking experts at Microsoft needed in order to take action on the needs of this project,” Shepperd says. “Without help from their teams, we would not have been able to deliver on our research goals as quickly and efficiently as we did.”

Lessons learned from the world’s second underwater datacenter

The research on Project Natick pays dividends in Microsoft’s future work, particularly around running more sustainable datacenters that could power Microsoft Azure cloud services.

“Whether a datacenter is on land or in water, the size and scale of Project Natick is a viable blueprint for datacenters of the future,” Shepperd says. “Instead of putting down acres of land for datacenters, our customers and competitors are all looking for ways to power their compute and to house storage in a more sustainable way.”

This experience taught Chaparala to assess the needs of his partner teams.

“We work with customers to understand their requirements and come up with objectives and key results that align,” Chaparala says.

Ultimately, Project Natick’s story is one of cross-disciplinary collaboration – and just in the nick of time.

“It’s exciting to play a role in bringing the right engineers and program managers together for a common goal, especially so quickly,” Chaparala says. “Once we had the right team, we knew there was nothing we couldn’t handle.”

• Watch this video about Microsoft’s findings from Project Natick, the experimental undersea datacenter.
• Learn how Microsoft rebuilt its VPN infrastructure.
• Find out how Microsoft Digital is using a modern network infrastructure to drive transformation at Microsoft.

The post How Microsoft kept its underwater datacenter connected while retrieving it from the ocean 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.

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.

We’re building a more agile, resilient, and stable virtual wide-area network (VWAN) to create a better experience for our employees to connect and collaborate globally. By implementing a continuous integration/continuous deployment (CI/CD) approach to building our VWAN-based network infrastructure, we can automate the deployment and configuration processes to ensure rapid and reliable delivery of network changes. Here’s how we’re making that happen internally at Microsoft.

Infrastructure as code (IaC)

Infrastructure as code (IaC) is the fundamental principle underlying our entire VWAN infrastructure. Using IaC, we can develop and implement a descriptive model that defines and deploys VWAN components and determines how the components work together. IaC allows us to create and manage a massive network infrastructure with reusable, flexible, and rapid code deployments.

We created deployment templates and resource modules using the Bicep language in our implementation. These templates and modules describe the desired state of our VWAN infrastructure in a declarative manner. Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Microsoft Azure resources.

We maintain a primary Bicep template that calls separate modules—also maintained in Bicep templates—to create the desired resources for the deployment in alignment with Microsoft best practices. We use this modular approach to apply different deployment patterns to accommodate changes or new requirements.

With IaC, changes and redeployments are as quick as modifying templates and calling the associated modules. Additionally, parameters for each unique deployment are maintained in separate files from the templates so that different iterations of the same deployment pattern can be deployed without changing the source Bicep code.

Version control

We use Microsoft Azure DevOps, a source control system using Git, to track and manage our IaC templates, modules, and associated parameter files. With Azure DevOps, we can maintain a history of changes, collaborate within teams, and easily roll back to previous versions if necessary.

We’re also using pull requests to help track change ownership. Azure DevOps tracks changes and associates them with the engineer who made the change. Azure DevOps is a considerable help with several other version control tasks, such as requiring peer reviews and approvals before code is committed to the main branch. Our code artifacts are published to (and consumed from) a Microsoft Azure Container Registry that allows role-based access control of modules. This enables version control throughout the module lifecycle, and it’s easy to share Azure Container Registry artifacts across multiple teams for collaboration.

Automated testing

Responsible deployment is essential with IaC when deploying a set of templates could radically alter critical network infrastructure. We’ve implemented safeguards and tests to validate the correctness and functionality of our code before deployment. These tests include executing the Bicep linter as part of the Azure DevOps deployment pipeline to ensure that all Bicep best practices are being followed and to find potential issues that could cause a deployment to fail.

We’re also running a test deployment to preview the proposed resource changes before the final deployment. As the process matures, we plan to integrate more testing, including network connectivity tests, security checks, performance benchmarks, and enterprise IP address management (IPAM) integration.

Configuration management

Azure DevOps and Bicep allow us to automate the configuration and provisioning of network objects and services within our VWAN infrastructure. These tools make it easy to define and enforce desired configurations and deployment patterns to ensure consistency across different network environments. Using separate parameter files, we can rapidly deploy new environments in minutes rather than hours without changing the deployment templates or signing in to the Microsoft Azure Portal.

Continuous deployment

The continuous integration (CI) pipeline automates the deployment process for our VWAN infrastructure when the infrastructure code passes all validation and tests. The CI pipeline triggers the deployment process automatically, which might involve deploying virtual machines, building and configuring cloud network objects, setting up VPN connections, or establishing network policies.

Monitoring and observability

We’ve implemented robust monitoring and observability practices for how we deploy and manage our VWAN deployment. Monitoring and observability are helping us to ensure that our CI builds are successful, detect issues promptly, and maintain the health of our development process. Here’s how we’re building monitoring and observability in our Azure DevOps CI pipeline:

• We’re creating built-in dashboards and reports that visualize pipeline status and metrics such as build success rates, durations, and failure details.
• We’re generating and storing logs and artifacts during builds.
• We’ve enabled real-time notifications to help us monitor build status for failures and critical events.
• We’re building-in pipeline monitoring review processes to identify areas for improvement including optimizing build times, reducing failures, and enhancing the stability of our pipeline.

We’re continuing to iterate and optimize our monitoring practices. We’ve created a feedback loop to review the results of our monitoring. This feedback provides the information we need to adjust build scripts, optimize dependencies, automate certain tasks, and further enhance our pipeline.

By implementing comprehensive monitoring and observability practices in our Azure DevOps CI pipeline, we can maintain a healthy development process, catch issues early, and continuously improve the quality of our code and builds.

Rollback and rollforward

We’ve built the ability to rollback or rollforward changes in case of any issues or unexpected outcomes. This is achieved through infrastructure snapshots, version-controlled configuration files, or using features provided by our IaC tool.

Improving through iteration

We’re continuously improving our VWAN infrastructure using information from monitoring data and user experience feedback. We’re also continually assessing new requirements, newly added Azure features, and operational insights. We iterate on our infrastructure code and configuration to enhance security, performance, and reliability.

By following these steps and using CI/CD practices, we can build, test, and deploy our VWAN network infrastructure in a controlled and automated manner, creating a better employee experience by ensuring faster delivery, increased stability, and more effortless scalability.

Here are some tips on how you can start tackling some of the same challenges at your company:

• You can use Infrastructure as code (IaC) to create and manage a massive network infrastructure with reusable, flexible, and rapid code deployments.
• Using IaC, you can make changes and redeployments quickly by modifying templates and calling the associated modules.
• Don’t overlook version control. Tracking and managing IaC templates, modules, and associated parameter files is essential.
• Perform automated testing. It’s necessary to validate the correctness and functionality of the code before deployment.
• Use configuration management tools to simplify defining and enforcing desired configurations and deployment patterns. This ensures consistency across different network environments.
• Implement continuous deployment to automate the deployment process for network infrastructure after the code passes all validation and tests.
• Use monitoring and observability best practices to help identify issues, track performance, troubleshoot problems, and ensure the health and availability of the network infrastructure.
• Building rollback and roll-forward capabilities enables you to quickly respond to issues or unexpected outcomes.

Try using a Bicep template to manage your Microsoft Azure resources.

• Discover boosting our connectivity with our own next-generation optical network.
• Unpack running on VPN: How Microsoft is keeping its remote workforce connected.
• Explore implementing Microsoft Azure cost optimization internally at Microsoft.
• Check out building a secure and efficient self-service application using Azure ACI, Azure Compute Gallery, and the Microsoft Azure SDK.

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

The post How we’re deploying our VWAN infrastructure using infrastructure as code and CI/CD appeared first on Inside Track Blog.

They were cautiously optimistic—the team had just rebuilt the entire network, including the virtual private network (VPN). This network supports access to key internal servers with protected data, personnel information, and other critical assets that must be on lockdown.

“Our network has done very well for employees to working remotely,” Means says. “So far, we’ve seen a really strong performance from our network and VPN, specifically.”

The strong response has been fueled by an earlier decision the team made to reduce the workload that the company pushes through its VPN pipes. The team did that by implementing split tunneling at most of its locations worldwide, which funnels the majority of the company’s mobile workload to the internet.

Split tunneling became possible because Microsoft is nearly 100 percent in the cloud, which allows its remote workers to access core applications and experiences over the internet via Microsoft Azure and Office 365. Before the company migrated to the cloud, everything would have been routed through VPN.

“It really helps us that most of our mobile workload—including traffic to high volume and performance sensitive Office 365 and Azure applications—is securely routed directly over the internet,” Means says.

In retrospect, adopting split tunneling was a pivotal decision.

“It is allowing our employees to maintain their normal level of productivity even as they work remotely,” he says.

He pointed to how employees are now using Microsoft Teams as an example.

“Our employees have significantly increased their usage of voice and video conferencing on Teams,” he says. “We’ve been able to sustain this massive spike in Teams usage without major issues because it’s being routed over the internet—leaving our VPN capacity for just necessary connections between users and our internal resources.”

There have been challenges, however, which began when the Microsoft’s employees in China started working from home.

“Unlike here at our headquarters and other worldwide locations, when our employees in China work remotely, everything they do goes exclusively through our VPN pipe,” Means says.

That meant 100 percent of the workload of employees in Shanghai and Beijing was suddenly going through already heavily used VPN gateways.

“It was almost an overnight phenomenon,” Means says. “We were suddenly seeing usage of 85 to 95 percent of our network bandwidth and our VPN capacity.”

Already tight before the spread of COVID-19 began, VPN was quickly becoming a bottleneck in China.

“We started asking ourselves a lot of questions,” Means says. “Can we handle the expected number of concurrent VPN sessions? How is bandwidth holding up for employees? What’s their experience like? Are they all being successful?”

Quick action was needed.

“We had data to answer all the questions, but what we didn’t have was a single pane of glass where we could quickly look at everything to see what was happening across the company’s infrastructure,” Means says. “And company leaders were trying to figure out how to respond to the crisis—they needed data from us, and they needed it quickly.”

The answer was to identify the data that mattered the most and aggregate it into a Microsoft Power BI dashboard, which the company now uses to track all its VPN systems as the COVID-19 situation evolves.

As for the offices in Shanghai and Beijing, Means’s team worked with local internet providers to increase VPN capacity by 50 percent so they had enough headroom to handle the new usage safely.

“That was a budget decision,” Means says. All they had to do was sign some contracts—no new hardware was needed. “Once we agreed that it was the right thing to do, we were able to remove that bottleneck in less than a day.”

[Explore using a Zero Trust strategy to secure Microsoft’s network during remote work. Unpack enhancing VPN performance at Microsoft. Discover how Microsoft Sentinel protects Microsoft from cybersecurity attacks.]

Investments in VPN infrastructure paying off

The notion of Microsoft’s employees and vendors frequently working remotely was daunting, but Means was confident that its VPN infrastructure would support that sudden spike in demand.

Three years ago, he would not have been so optimistic.

“We were in a tough spot a few years ago,” Means says. “We had multiple and complex reasons for why our employees’ end-to-end VPN experience wasn’t very strong—it was a complicated stack that had multiple potential failure points.”

The team ran into issues on the Windows side, there were challenges with the network, and the company was using several different VPN clients at once, which created confusion and complexity for employees. Means’s team worked closely with the Windows team, and through direct partnership and engagement, helped drive significant stability improvements in the Windows native VPN client.

“We saw a connectivity success rate in the 60 to 65 percent range, which is very low,” Means says. “That meant that a third of people would run into an issue every time they tried to work remotely.”

A fix was needed.

“We knew this could become a problem if we had a situation where we needed many of our employees to work remotely,” Means says. “So, we invested heavily in strengthening our VPN service by focusing on the user experience and partnering closely with internal teams.”

“We built the new system so it could support over 200,000 concurrent sessions,” Means says. “In an extreme situation, we could support that many people on VPN at the same time.”

Microsoft has 221,000 employees and a large contingent of vendors who work on the company’s network. They don’t all work at the same time, but the goal was to cover the worst-case scenario and to future-proof the solution.

“Across the world, we normally have about 55,000 employees connect via VPN on a given day,” Means says. “With everyone working remotely, that has climbed as high as 128,000 employees and vendors per day, including about 45,000 per day at our headquarters in Redmond.”

Previously, employees used a large number of gateways to access the company’s internal network, but many of those gateways provided poor connectivity.

“We consolidated the gateways to data centers and locations with reliable and plentiful bandwidth,” Means says. “This shrunk the number of gateway sites, but increased overall reliability and made it so we could handle more concurrent connections.”

The hybrid design that the team put together uses Microsoft Azure Traffic Manager to geolocate VPN users. “That allowed us to send them to their nearest gateway and to meet scale demands,” he says. “We used Azure Active Directory (AAD) to authenticate our users and to validate the status of their device before allowing them on VPN.”

The team also began using servers that can handle 30,000 or 60,000 users each, much more than the old servers that could only handle 750 to 2,000 users. “Theoretically, we could now handle 500,000 concurrent VPN connections worldwide,” Means says.

Means says the improvement in the company’s VPN service was substantial, so much so that employees forgot it was working behind the scenes when they worked remotely.

Despite being worked harder than ever before, the company’s VPN infrastructure is performing at a high level. “Knock on wood, there have been no major incidents,” Means says.

Importantly, VPN is allowing employees to get their work done.

“Today, even as many of our employees work remotely, our success rate is at 92 percent,” Means says. “That’s one of the highest rates we’ve ever recorded—the only reason it isn’t at 99 percent is because that number includes drops because of reboots during patch updates, getting disconnected from Wi-Fi, and home network or internet service provider issues.”

Employee productivity also has held strong.

“We measure employee productivity, and the productivity of our software engineers in particular,” Means says. “We look at pull requests, commits per day, and other indicators—so far, we haven’t seen any measurable drop in work performance.”

Means says the situation is creating a learning moment for his team.

“One thing that we’re learning is it’s really about the data,” he says. “There are so many things we can measure—finding the right things to measure so we can take the right actions is critical.”

The team’s data-centric approach to VPN and networking also has allowed it to make smart investments, like provisioning capacity only when required. It also helps the team respond quickly when needed—as was the case when Italy tightened its remote working restrictions.

“We doubled capacity in London, which is where we run the VPN connection for our employees in Italy,” Means says. “Having good data allows us to quickly take proactive action when needed and to stay ahead of the game at all times.”

The team also saw the potential for a bottleneck at its headquarters in Redmond, Washington, where the number of concurrent sessions that VPN needed to support was climbing close to capacity. The company addressed this concern by adding another VPN gateway.

“This has caused us to reflect on our readiness efforts overall,” Means says. “We’ve used this as an opportunity to improve how we do things.”

The team expects to keep learning and adding to the VPN capabilities.

Tips for retooling VPN at your company

For enterprises and organizations looking to optimize and scale out their VPN capabilities, some of the best practices shown above and recommended by Microsoft are:

• Consider saving the load on your VPN infrastructure by using split tunnel VPN, send networking traffic directly to the internet for “known good” and well-defined SaaS services like Teams and other Office 365 services, or optimally, by sending all non-corporate traffic to the internet if your security rules allow.
• Collect user connection and traffic data in a central location for your VPN infrastructure, use modern visualization services, like Power BI, to identify hot spots before they happen, and plan for growth.
• Utilize Azure Sentinel to organize log collections, including user connection and traffic data, in a central location for VPN infrastructure.
• If possible, use a dynamic and scalable authentication mechanism, like Azure Active Directory, to avoid the trouble of certificates and improve security using multi-factor authentication (MFA) if your VPN client is Active Directory aware, like the Azure OpenVPN client.
• Geographically distribute your VPN sites to match major user populations, use a geo-load balancing solution such as Azure Traffic Manager, to direct users to the closest VPN site and distribute traffic between your VPN sites.

Finally, and probably most important, know the limits of your VPN connection infrastructure and how to scale out in times of need. Things like total bandwidth possible, maximum concurrent user connections per device will determine when you’ll need to add more VPN devices.

If your devices are physical hardware having additional supply on-hand or a rapid supply chain source will be critical. For cloud solutions, knowing ahead of time how and when to scale will make the difference.

Azure offers a native highly-scalable VPN gateway, as well the most common third-party VPN and SDWAN 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 VPN Gateways
• Azure Point-to-site VPN
• VPN Network Virtual Appliances in the Azure Marketplace
• Updates for improving work-from-home employee access

• Explore using a Zero Trust strategy to secure Microsoft’s network during remote work.
• Unpack enhancing VPN performance at Microsoft.
• Discover boosting Microsoft’s response to cybersecurity attacks with Microsoft Sentinel.

The post Running on VPN: How Microsoft is keeping its remote workforce connected appeared first on Inside Track Blog.

We thought it would be useful to share our answers to the Top 10 Zero Trust questions from customers across the globe.

It’s surprising to us how many companies haven’t embraced multifactor authentication. It’s the first step we took on our Zero Trust journey.

– Mark Skorupa, principal program manager

If you had to pick, what are your top three Zero Trust best practices?

Microsoft’s approach to Zero Trust means we don’t assume any identity or device on our corporate network is secure, we continually verify it.

With that as context, our top three practices revolve around the following:

• Identities are secure using multifactor authentication (MFA): It’s surprising to us how many companies haven’t embraced multifactor authentication. It’s the first step we took on our Zero Trust journey. Regardless of what solution you decide to implement, adding a second identity check into the process makes it significantly more difficult for bad actors to leverage a compromised identity over just passwords alone.
• Device(s) are healthy: It’s been crucial that Microsoft can provide employees secure and productive ways to work no matter what device they’re using or where they’re working, especially during remote or hybrid work. However, any devices that access corporate resources must be managed by Microsoft and they must be healthy, meaning, they are running the latest software updates and antivirus software.
• Telemetry is pervasive: The health of all services and applications must be monitored to ensure proper operation and compliance and enable rapid response when those conditions are not met. Before granting access to corporate resources, identities and devices are continually verified to be secure and compliant. We monitor telemetry looking for signals to identify anomalous patterns. We use telemetry to measure risk reduction and understand the user experience.

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

Does Microsoft require Microsoft Intune enrollment on all personal devices? Can employees use their personal laptops or devices to access corporate resources?For employees who want access to Microsoft corporate resources from a personal device, we require that devices be enrolled in Microsoft Intune. If they don’t want to enroll their personal device, that’s perfectly fine. They can access corporate resources through the following alternative options:

• Windows Virtual Desktop allows employees and contingent staff to use a virtual remote desktop to access corporate resources like Microsoft SharePoint or Microsoft Teams from any device.
• Employees can use Outlook on the web to access their Microsoft Outlook email account from the internet.

How does Microsoft onboard its Internet of Things (IoT) devices under the Zero Trust approach?

IoT is a challenge both for customers and for us.

Internally, Microsoft is working to automate how we secure IoT devices using Zero Trust. In June, the company announced the acquisition of CyberX, which will complement existing Microsoft Azure IoT security capabilities.

We segment our network and isolate IoT devices based on categories, including high-risk devices (such as printers); legacy devices (like digital coffee machines) that may lack the security controls required; and modern devices (such as smart personal assistant devices like an Amazon Echo) with security controls that meet our standards.

How is Microsoft moving away from VPN?

We’ve made good progress in moving away from VPN by migrating legacy, on-premises applications to cloud-based applications. That said, we still have more work to do before we can eliminate VPN for most employees. With the growing need to support remote work, we moved quickly to redesign Microsoft’s VPN infrastructure by adopting a split-tunneled configuration where traffic is directly routed to the applications available in the cloud and through VPN for any legacy applications. The more legacy applications we make available directly from the internet, the less we need VPN.

How do you manage potential data loss?

Everyone at Microsoft is responsible for protecting data, and we have specific scenarios that call for additional security when accessing sensitive data. For example, when an employee needs to make changes to customer-facing production systems like firewalls, they use privileged access workstations, a dedicated operating system for sensitive tasks.

Our employees also use features in Microsoft Information Protection, like the sensitivity button in Microsoft 365 applications to tag and classify documents. Depending on the classification level—even if a document moves out of our environment—it can only be opened by someone that was originally provided access.

How can Zero Trust be used to isolate devices on the network to further reduce an attack surface?

The origins of Zero Trust were focused on micro-segmentation of the network. While Microsoft’s focus extends beyond the physical network and controlling assets regardless of connectivity or location, there is still a strong need for implementing network segmentation within your physical network.

We currently have segmented our network into the configuration shown in the following diagram, and we’re evaluating future segments as the need arises. For more details on our Zero Trust strategy around networking, check out Microsoft’s approach to Zero Trust Networking and supporting Azure technologies.

How do you apply Zero Trust to a workstation where the user is a local admin on the device?

For us, it doesn’t matter what the device or workstation is, or the type of account used—any device that is looking for access to corporate resources needs to be enrolled and managed by Microsoft Intune, our device management service. That said, our long-term vision is to build an environment where standard user accounts have the permission levels to be just as productive as local admin accounts.

How important is it to have Microsoft Azure AD (AAD), even if we have Active Directory (AD) on-premises, for Zero Trust to work in the cloud? Can on-premises Active Directory alone work to implement Zero Trust if we install Microsoft Monitoring Agent (MMA) to it?

Because Microsoft has shifted most of our security infrastructure to the Microsoft Azure cloud, using Microsoft Azure AD Conditional Access is a necessity for us. It helps automate the process and determine which identities and devices are healthy and secure, which then enforces the health of those devices.

Using MMA would get you to some level of parity, but you wouldn’t be able to automate device enforcement. Our recommendation is to create an AAD instance as a replica of your on-premises AD. This allows you to continue using your on-premises AD as the master but still leverage AAD to implement some of the advanced Zero Trust protections.

How do you deal with Zero Trust for guest access scenarios?

When allowing guests to connect to resources or view documents, we use a least-privileged access model. Documents tagged as public are readily accessible, but items tagged as confidential or higher require the user to authenticate and receive a token to open the documents.

We also tag resources like Microsoft SharePoint or Microsoft Teams locations that block guest access capabilities. Regarding network access, we provide a guest wireless service set identifier (SSID) for the guest to connect to which are isolated with internet only access. Finally, all guest accounts are required to meet our MFA requirements prior to granting access.

We hope this guidance is helpful to you no matter what stage of the Zero Trust journey you’re on. As we look to 2021, the key lesson is to have empathy. Understanding where an employee is coming from and being transparent with them about why a policy is shifting or how it may impact them is critical.

– Mark Skorupa, principal program manager

What’s your Zero Trust priority for 2021?

We’re modernizing legacy and on-premises apps to be available directly from the internet. Making these available, even apps with legacy authentication requirements, allows our device management service to apply conditional access, which enforces verification of identities and ensures devices are healthy.

We hope this guidance is helpful to you no matter what stage of the Zero Trust journey you’re on. As we look to the rest of 2021, our team continues to come back to is the importance of empathy. Understanding where an employee is coming from and being transparent with them about why a policy is shifting or how it may impact them is critical.

Microsoft wasn’t born in the cloud either, so many of the digital security shifts we’re making by taking a Zero Trust approach aren’t familiar to our employees or can be met with hesitancy. We take ringed approaches to everything we roll out, which enables us to pilot, test, and iterate on our solutions based on feedback.

Leading with empathy keeps us focused on making sure employees are productive and efficient, and that they can be stewards of security here at Microsoft and with our customers.

• Read this article about how Microsoft is adopting a Zero Trust security model to secure corporate and customer data.

The post Microsoft’s digital security team answers your Top 10 questions on Zero Trust appeared first on Inside Track Blog.

Few places on earth can echo the harsh, alien environment of the Himalayan mountains in the winter, and fewer still are the number of people who live there. Those who do, the Sherpa of Khumbu, are as rugged as the steep cliffs they count as home. As with all cultures, their children hold the future of the Sherpa’s way of life in their hands.

With that in mind, how do the Sherpa people ensure their children’s ability to thrive when their access to education and technology is often limited?

A group of industrious Microsoft engineers and program managers from the United States, Hong Kong, Istanbul, France, and Canada believe bringing technology to them will empower them to start to answer this question and, along the way, hopefully begin their journey to leap across the opportunity divide.

A team led by Doug Pierson from Microsoft Core Services Engineering and Operations (CSEO) just returned from a visit with schoolchildren who live in remote villages in Nepal. Climbing as high as 15,160 feet above sea level, the team hiked from Lukla to Farak Peak, and back again, a seven-day roundtrip. They brought Microsoft technology and school supplies to villages, schools, and monasteries in the Khumbu Region of Nepal, including 40 Microsoft Surface 3 tablets.

“It’s all for the children,” Pierson says. “They are the future.”

Every step was another groan of the foot and back, and another gasping breath in the thin air. Jagged cliffs and rocky terrain pushed the crew to its limits, something they were only able to get through by relying on each other.

Even for a trained U.S. Marine like Pierson it was challenging, and even more so for his companions. Accompanying him were Alex Agudelo, Claire Sisson, Darren Moffatt, Mandy Yeung, Orhan Topcu, Robert Koester, and Ugur Yilmaz, all of them experts within their respective technology-related fields in IT, gaming cloud, and global security. They were assisted on their journey by Mark Gunlogson, who they partnered with and is president of Mountain Madness, and Chappal Sherpa—their very skilled guide of this rough terrain.

Helping young students in such a remote location showcases the culture and mission of Microsoft to empower every person and every organization on the planet to achieve more, Pierson says.

This is not the first global citizenship mission Pierson has led on behalf of CSEO. Over the past eight years, he and a core team of his colleagues have traveled to and in support of nonprofits from Cambodia to Los Angeles on trips focused on children’s education and empowerment. Read this story on how the team traveled to Thessaloniki, Greece, to support a camp of Syrian refugees.

“We as employees drive each other forward,” he says. “We want to impact the rest of the world. This is how change is driven, this is what effective leadership is all about. Sometimes the way you develop as a professional in the tech field, or as a team, includes some unorthodox moments.”

Moments like taking a pilgrimage through the tallest mountains in the world.

The journey to Nepal added a new challenge that set it apart from the team’s previous travels. A truly raw, physical trial with every step they took, every single member of the team needed each other to push through to the end. From having to weave their way around yaks and mules, to crossing a hanging bridge that swung back and forth 100 meters above the Dudh Khosi River, to coping with weather that changed moment by moment, the team took nothing for granted.

All of this was worth it when they reached the children. Excited to have visitors, Sherpa children from each of the villages they visited were consistently eager to show their proficiency in English, giggling as they willingly spoke with the team, offering local foods to the group with giant smiles. The team stayed at each location long enough to make sure that supplies were set up for use, any questions were answered, and school administrators understood how to work with their new devices.

As a karmic bonus, the team returned home with new mindsets and perspectives to share with others who work in IT at CSEO and Microsoft at large. This is often the result of creative, on-the-spot solutions to technical problems that the group comes up with on these trips, solutions to challenges that may not be encountered by people who have access to affordable and reliable technological services, Pierson says.

In the Khumbu region, electricity itself is not something that can be accessed whenever it is desired—it is expensive, and often the wires and other electrical infrastructure is faulty or not functional.

“We see issues in more remote locations that we may not anticipate, as they don’t have access to all of the technological conveniences that we’ve grown accustomed to,” Pierson says.

For example, the lack of a consistent supply of electricity and internet connection in the Himalayas can mean that using cloud services isn’t an option. Seeing these kinds of challenges first-hand can help Microsoft employees think about how to plan for them when building the company’s products and services back in Redmond.

“Being so remote and having a lack of electricity is really something that seems unrelated to the work we do until you stop and think about it,” Pierson says. “But these experiences can be powerful catalysts for change in ways of thinking, and the way you approach innovation.”

All the members of the team say it was a unique and rewarding experience to travel deep into the Himalayas as a way of giving back. They say they have been deeply affected by how the Sherpa people take nothing for granted. A common phrase used in the Khumbu Region that resonated with them is the Buddhist notion that ‘nothing is permanent,’ a mindset that lends itself towards growth and resourcefulness.

The team also took away another Buddhist learning, one thought to be Buddha’s last words in ~400 BC, which was “do your best.” “That’s a fitting message for us all, no matter where we are, and no matter what we do for this incredible company that we are all a part of,” Pierson says.

Read a past Showcase blog series on the team’s visit to Thessaloniki, Greece, here.

The post Climbing to the edge of the world to help children leap across the opportunity divide appeared first on Inside Track Blog.