Tag: Recent News

Like many this year, our Microsoft workforce had to quickly transition to a work from the home model in response to COVID-19. While nobody could have predicted the world’s current state, it has provided a very real-world test of the investments we have made implementing a Zero Trust security model internally. We had about 97 percent of our workforce at the peak successfully working from home, either on a Microsoft issued or personal device. 

Much of the credit for this success goes to the Zero Trust journey we started over three years ago. Zero Trust has been critical in making this transition to a work-from-home model relatively friction-free. One of the major components to our Zero Trust implementation is ensuring our employees have access to applications and resources regardless of their location. We enable employees to be productive from anywhere, whether they’re at home, a coffee shop, or at the office.  

To make this happen, we needed to make sure most of our resources were accessible over any internet connection. The preferred method to achieve this is through modernizing applications and services using the cloud and modern authentication systems. For legacy applications or services unable to migrate to the cloud, we use an application proxy service which serves as a broker to connect to the on-premise environment while still enforcing strong authentication principles.  

Strong authentication and adaptive access policies are critical components in the validation process. A big part of this validation process included enrolling devices in our device management system to ensure only known and healthy devices are directly accessing our resources. For users on devices that are not enrolled in our management system, we have developed virtualization options that allow them to access resources on an unmanaged device. One of the early impacts of COVID-19 was device shortages and the inability to procure new hardware. Our virtualization implementation also helped provide secure access for new employees while they waited for their device’s arrival. 

The output of these efforts, combined with a VPN configuration that enables split tunneling for access to the few remaining on-premises applications, has made it possible for Microsoft employees to work anywhere in a time when it is most critical. 

Implementing an internet-first model for your applications

In this blog, I will share some recommendations on implementing an internet-first approach plus a few of the things we learned in our efforts here at Microsoft. Because every company has its own unique culture, environments, infrastructure, and threshold for change, there is no one-size-fits-all approach. Hopefully, you will find some of this information useful, even if only to validate you are already on the right path. 

Before I jump in, I just want to mention that this blog will assume you’ve completed some of the foundational elements needed for a Zero Trust security model. These include modernizing your identity system, verifying sign-ins with multi-factor authentication (MFA), registering devices, and ensuring compliance with IT security policies, etc. Without these protections in place, moving to an internet-first posture is not possible. 

As previously mentioned, your apps will need to be modernized by migrating them to the cloud and implementing modern authentication services. This is the optimal path to internet accessibility. For apps that can’t be modernized or moved to the cloud (think legacy on-premises apps), you can leverage an app proxy to allow the connection over the internet and still maintain the strong authentication principles. 

Secure access via adaptive access policies

 Once your apps are accessible via the public internet, you will want to control access based on conditions you select to enforce. At Microsoft, we use Conditional Access policies to enforce granular access control, such as requiring multi-factor authentication, based upon user context, device, location, and session risk information. We also enforce device management and health policies to ensure the employee comes from a known and healthy device once they have successfully achieved strong authentication. 

 Depending on your organization’s size, you might want to start slow by implementing multi-factor authentication and device enrollment first, then ramping up to biometric authentication and full device health enforcement. Check out our Zero Trust guidance for identities and devices that we follow internally for some additional recommendations. 

 When we rolled out our device enrollment policy, we learned that using data to measure the policy’s impact allowed us to tailor our messaging and deployment schedule. We enabled “logging mode”, which let us enable the policies and collect data on who would be impacted when we moved to enforcement. Using this data, we first targeted users who were already using compliant devices. For users that we knew were going to be impacted, we crafted targeted messaging alerting them of the upcoming changes and how they would be impacted. This slower, more measured deployment approach allowed us to monitor and respond to issues more quickly. Using this data to shape our rollout helped us minimize the impact of significant policy implementation. 

Start with a hero application

Picking your first application to move out to the public internet can be done in a few different ways. Do you want to start with something small and non-critical? Or perhaps you want to “flip the switch” to cover everything at once? We decided to start with a hero application that proved it works at scale. Office 365 was the obvious choice because it provided the broadest coverage since most employees use it daily, regardless of what role they are in. We were confident if we could implement Office 365 successfully, we could be successful with most of our portfolio. 

Ultimately, it will boil down to your environment, threshold for support engagements, and company culture. Choose the path that works best for you and push forward. All paths will help provide valuable data and experience that will help later.  

Prioritize your remaining apps and services

Prioritizing the apps and services you modernize next can be challenging, especially without granular visibility into what employees are accessing in your environment. When we began our journey, we had theories about what people were accessing but no data to back it up. We built a dashboard that reported actual traffic volumes to applications and services still routing to on-premises applications and services to provide the visibility we lacked. This gave us much-needed information to help prioritize apps and services based on impact, complexity, risk, and more.  

We also used this dashboard to identify which application or service owners we needed to coordinate with to modernize their resources. To coordinate with these owners, we created work items in our task tracking system and assigned the owner a deadline to provide a plan to either modernize or implement a proxy front end solution. We also created a tracking dashboard for all these tasks and their status to make reporting easier.  

We then worked closely with owners to provide guidance and best practices to drive their success. We conduct weekly office hours where application and service owners can ask questions. The partnership between these application and service owners and the teams working on Zero Trust helps us all drive towards the same common goals—frictionless access for our employees. 

A quick note on what we learned through the dashboard—the on-premises applications and services people were still accessing were not what we were expecting. The dashboard surfaced several items we were unaware people were still using. Fortunately, the dashboard helped remove a layer of fog we were unaware even existed and has been invaluable in driving our prioritization efforts. 

As I mentioned at the beginning of this blog, every company is unique. As such, how you think about Zero Trust and your investments might be different than the company across the street. I hope some of the insight provided above was helpful, even if it is just to get you thinking about how you would approach solving some of these challenges inside your own organization.  

 To learn more about how Microsoft IT (Information Technology), check out IT Showcase. To learn more about Microsoft Security Solutions visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news on cybersecurity.  

Ransomware is a type of malware that holds computer systems or data hostage with demands for payment. And it has been used against a wide variety of targets, including governments, businesses and health care facilities. Ransomware distributors are also part of a wider web of digital menace that has threatened election security.

In October 2020, the Microsoft Digital Crimes Unit worked with a coalition of partners to disrupt Trickbot, one of the most infamous botnets and prolific distributors of ransomware. Botnets are networks of computers infected by malware and being used to commit cybercrimes. While disrupting a botnet is challenging work and success varies over time, Microsoft and its partners were able to disrupt 94% of Trickbot’s critical operational infrastructure in six days.

Jason Lyons is a malware and cloud crime investigator at the Microsoft DCU and part of a team that disrupted Trickbot. We caught up with Jason to find out more about this critical work. Below is an edited version of our conversation.

What is the Microsoft Digital Crimes Unit?

I don’t think there’s another organization in private industry with the same structure, components and skill sets. It sits within the Customer Security and Trust team at Microsoft, and it comprises many different jobs and skills, including lawyers and paralegals, cyber analysts, security researchers and investigators, like myself, as well as the engineers who help build the tools we need. We have about 65 people working around the globe – at Microsoft’s Redmond, Washington, headquarters, Asia, Europe and South America.

How do people come to work in the team? What did you do beforehand?

I used to be a special agent in the U.S. Army, doing counterintelligence work. Our investigators come from many different backgrounds. One of my colleagues in DCU was a colonel in the Army, working in the communications sector. Another investigator who joined DCU recently was a computer scientist for the FBI. Another is an attorney. So there are lots of different backgrounds on the team.

[READ MORE: Protecting democracy, especially in a time of crisis]

What does your work at the DCU involve?

Within my team, which is one of about four within the DCU, we carry out about two or three major botnet disruptions – like the Trickbot operation – a year. Then we work with product teams within Microsoft, particularly Microsoft Defender and Office 365, to ensure we’re on top of current threats, as well as tackling any internal security issues. Our goal is to stop the spread of malware and protect our customers and users of the internet.

The DCU tackles the biggest threats in the ecosystem. We primarily focus on those that are having the biggest impact on our customers … or as important to a partner like FS-ISAC [the financial services cyber intelligence sharing body], which represents financial institutions all over the world. Trickbot was brought to our attention because of its antivirus (AV) tampering – once it infects a system, it has the ability to turn off the AV product.

When a case is referred to the DCU, what happens next?

They’re usually brought to us by someone inside our product group saying, “Hey, this is a significant problem for us.” We evaluate the issue, looking at the impact it could have not just on Microsoft but more widely, too. We ask whether there’s infrastructure to disrupt, where the bad guys are located and where they’re hosting their servers – and if we can get a U.S. court order to disrupt them. Or, will we need international partners and possibly international judicial orders, all of which is possible with our global team. Then we investigate how the botnet operates – is there a vulnerability we can exploit to disconnect the criminals from the victim machines and cause a significant disruption?

How are these weaknesses identified?

We build automated systems to dissect the information in the files that the botnet sends out. Then we’ll take it into our malware lab to really find out how it works. We want to know how it infects the operating system and what it does next. What security protocols does it turn off? And we look at how it communicates – probably the most important thing is what the communication between the command and control server and the victim looks like.