{"id":9774,"date":"2024-06-21T05:50:21","date_gmt":"2024-06-21T12:50:21","guid":{"rendered":"https:\/\/www.microsoft.com\/insidetrack\/blog\/?p=9774"},"modified":"2024-06-20T08:26:30","modified_gmt":"2024-06-20T15:26:30","slug":"improving-security-by-protecting-elevated-privilege-accounts-at-microsoft","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/insidetrack\/blog\/improving-security-by-protecting-elevated-privilege-accounts-at-microsoft\/","title":{"rendered":"Improving security by protecting elevated-privilege accounts at Microsoft"},"content":{"rendered":"
An ever-evolving digital landscape is forcing organizations to adapt and expand to stay ahead of innovative and complex security risks. Increasingly sophisticated and targeted threats, including phishing campaigns and malware attacks, attempt to harvest credentials or exploit hardware vulnerabilities that allow movement to other parts of the network, where they can do more damage or gain access to unprotected information.<\/p>\n We on the Microsoft Digital Employee Experience (MDEE) team, like many IT organizations, used to employ a traditional IT approach to securing the enterprise. We now know that effective security calls for a defense-in-depth approach that requires us to look at the whole environment\u2014and everyone that accesses it\u2014to implement policies and standards that better address risks.<\/p>\n To dramatically limit our attack surface and protect our assets, we developed and implemented our own defense-in-depth approach. This includes new company standards, telemetry, monitoring, tools, and processes to protect administrators and other elevated-privilege accounts.<\/p>\n In an environment where there are too many administrators, or elevated-privilege accounts, there is an increased risk of compromise. When elevated access is persistent or elevated-privilege accounts use the same credentials to access multiple resources, a compromised account can become a major breach.<\/p>\n This blog post highlights the steps we are taking at Microsoft to protect our environment and administrators, including new programs, tools, and considerations, and the challenges we faced. We will provide some details about the new \u201cProtect the Administrators\u201d program that is positively impacting the Microsoft ecosystem. This program takes security to the next level across the entire enterprise, ultimately changing our digital-landscape security approach.<\/p>\n [Learn how we\u2019re protecting high-risk environments with secure admin workstations<\/a><\/em>. Read about implementing a Zero Trust security model at Microsoft.<\/a><\/i> Learn more about how we manage Privileged Access Workstations<\/a><\/em>.]<\/em><\/p>\n Securing all environments within your organization is a great first step in protecting your company. But there\u2019s no silver-bullet solution that will magically counter all threats. At Microsoft, information protection rests on a defense-in-depth approach built on device health, identity management, and data and telemetry\u2014a concept illustrated by the three-legged security stool, in the graphic below. Getting security right is a balancing act. For a security solution to be effective, it must address all three aspects of risk mitigation on a base of risk management and assurance\u2014or the stool topples over and information protection is at risk.<\/p>\n Though we would like to be able to fix everything at once, that simply isn\u2019t feasible. We created a risk-based approach to help us prioritize every major initiative. We used a holistic strategy that evaluated all environments, administrative roles, and access points to help us define our most critical roles and resources within the Microsoft ecosystem. Once defined, we could identify the key initiatives that would help protect the areas that represent the highest levels of risk.<\/p>\n As illustrated in the graphic below, the access-level roles that pose a higher risk should have fewer accounts\u2014helping reduce the impact to the organization and control entry.<\/p>\n The next sections focus primarily on protecting elevated user accounts and the \u201cProtect the Administrators\u201d program. We\u2019ll also discuss key security initiatives that are relevant to other engineering organizations across Microsoft.<\/p>\n After doing a deeper analysis of our environments, roles, and access points, we developed a multifaceted approach to protecting our administrators and other elevated-privilege accounts. Key solutions include:<\/p>\n In the past, equipment was primarily on-premises, and it was assumed to be easier to keep development, test, and production environments separate, secure, and well-isolated without a lot of crossover. Users often had access to more than one of these environments but used a persistent<\/em> identity<\/em>\u2014a unique combination of username and password\u2014to log into all three. After all, it\u2019s easier to remember login information for a persistent identity than it is to create separate identities for each environment. But because we had strict network boundaries, this persistent identity wasn\u2019t a source of concern.<\/p>\n Today, that\u2019s not the case. The advent of the cloud has dissolved the classic network edge. The use of on-premises datacenters, cloud datacenters, and hybrid solutions are common in nearly every company. Using one persistent identity across all environments can increase the attack surface exposed to adversaries. If compromised, it can yield access to all company environments. That\u2019s what makes identity today\u2019s true new perimeter.<\/p>\n At Microsoft, we reviewed our ecosystem to analyze whether we could keep production and non-production environments separate. We used our Red Team\/penetration (PEN) testers to help us validate our holistic approach to security, and they provided great guidance on how to further establish a secure ecosystem.<\/p>\n The graphic below illustrates the Microsoft ecosystem, past and present. We have three major types of environments in our ecosystem today: our Microsoft and Office 365 tenants, Microsoft Azure subscriptions, and on-premises datacenters. We now treat them all like a production environment with no division between production and non-production (development and test) environments.<\/p>\n Prior to embarking on the \u201cProtect the Administrators\u201d program, we felt it was necessary to evaluate every role with elevated privileges to determine their level of access and capability within our landscape. Part of the process was to identify tooling that would also protect company security (identity, security, device, and non-persistent access).<\/p>\n Our goal was to provide administrators the means to perform their necessary duties in support of the technical operations of Microsoft with the necessary security tooling, processes, and access capabilities\u2014but with the lowest level of access possible.<\/p>\n The top security threats that every organization faces stem from too many employees having too much persistent access. Every organization\u2019s goal should be to dramatically limit their attack surface and reduce the amount of \u201ctraversing\u201d (lateral movement across resources) a breach will allow, should a credential be compromised. This is done by limiting elevated-privilege accounts to employees whose roles require access and by ensuring that the access granted is commensurate with each role. This is known as \u201cleast-privileged access.\u201d The first step in reaching this goal is understanding and redefining the roles in your company that require elevated privileges.<\/p>\n We started with basic definitions. An information-worker account does not allow elevated privileges, is connected to the corporate network, and has access to productivity tools that let the user do things like log into SharePoint, use applications like Microsoft Excel and Word, read and send email, and browse the web.<\/p>\n We defined an administrator as a person who is responsible for the development, build, configuration, maintenance, support, and reliable operations of applications, networks, systems, and\/or environments (cloud or on-premises datacenters). In general terms, an administrator account is one of the elevated-privilege accounts that has more access than an information worker\u2019s account.<\/p>\n We used a role-based access control (RBAC) model to establish which specific elevated-privilege roles were needed to perform the duties required within each line-of-business application in support of Microsoft operations. From there, we deduced a minimum number of accounts needed for each RBAC role and started the process of eliminating the excess accounts. Using the RBAC model, we went back and identified a variety of roles requiring elevated privileges in each environment.<\/p>\n For the Microsoft Azure environments, we used RBAC, built on Microsoft Azure Resource Manager, to manage who has access to Azure resources and to define what they can do with those resources and what areas they have access to. Using RBAC, you can segregate duties within your team and grant to users only the amount of access that they need to perform their jobs. Instead of giving everybody unrestricted permissions in our Azure subscription or resources, we allow only certain actions at a particular scope.<\/p>\n We explored role attestation for administrators who moved laterally within the company to make sure their elevated privileges didn\u2019t move with them into the new roles. Limited checks and balances were in place to ensure that the right privileges were applied or removed when someone\u2019s role changed. We fixed this immediately through a quarterly attestation process that required the individual, the manager, and the role owner to approve continued access to the role.<\/p>\n We identified those roles that absolutely required elevated access, but not all elevated-privilege accounts are created equal. Limiting the attack surface visible to potential aggressors depends not only on reducing the number of elevated-privilege accounts. It also relies on only providing elevated-privilege accounts with the least-privileged access needed to get their respective jobs done.<\/p>\n For example, consider the idea of crown jewels kept in the royal family\u2019s castle. There are many roles within the operations of the castle, such as the king, the queen, the cook, the cleaning staff, and the royal guard. Not everyone can or should have access everywhere. The king and queen hold the only keys to the crown jewels. The cook needs access only to the kitchen, the larder, and the dining room. The cleaning staff needs limited access everywhere, but only to clean, and the royal guard needs access to areas where the king and queen are. No one other than the king and queen, however, needs access to the crown jewels. This system of restricted access provides two benefits:<\/p>\n This is the concept of least-privileged access: We only allow you access to a specific role to perform a specific activity within a specific amount of time from a secure device while logged in from a secure identity.<\/p>\n We can\u2019t truly secure our devices without having a highly secure datacenter to build and house our infrastructure. We used HVA to implement a multitiered and highly secure high-risk environment (HRE) for isolated hosting. We treated our HRE as a private cloud that lives inside a secure datacenter and is isolated from dependencies on external systems, teams, and services. Our secure tools and services are built within the HRE.<\/p>\n Traditional corporate networks were typically walled only at the external perimeters. Once an attacker gained access, it was easier for a breach to move across systems and environments. Production servers often reside on the same segments or on the same levels of access as clients, so you inherently gain access to servers and systems. If you start building some of your systems but you\u2019re still dependent on older tools and services that run in your production environment, it\u2019s hard to break those dependencies. Each one increases your risk of compromise.<\/p>\n It\u2019s important to remember that security awareness requires ongoing hygiene. New tools, resources, portals, and functionality are constantly coming online or being updated. For example, certain web browsers sometimes release updates weekly. We must continually review and approve the new releases, and then repackage and deploy the replacement to approved locations. Many companies don\u2019t have a thorough application-review process, which increases their attack surface due to poor hygiene (for example, multiple versions, third-party and malware-infested application challenges, unrestricted URL access, and lack of awareness).<\/p>\n The initial challenge we faced was discovering all the applications and tools that administrators were using so we could review, certify, package, and sign them as approved applications for use in the HRE and on SAWs. We also needed to implement a thorough application-review process, specific to the applications in the HRE.<\/p>\n Our HRE was built as a trust-nothing environment. It\u2019s isolated from other less-secure systems within the company and can only be accessed from a SAW\u2014making it harder for adversaries to move laterally through the network looking for the weakest link. We use a combination of automation, identity isolation, and traditional firewall isolation techniques to maintain boundaries between servers, services, and the customers who use them. Admin identities are distinct from standard corporate identities and subject to more restrictive credential- and lifecycle-management practices. Admin access is scoped according to the principle of least privilege, with separate admin identities for each service. This isolation limits the scope that any one account could compromise. Additionally, every setting and configuration in the HRE must be explicitly reviewed and defined. The HRE provides a highly secure foundation that allows us to build protected solutions, services, and systems for our administrators.<\/p>\n Secure admin workstations (SAWs)<\/a> are limited-use client machines that substantially reduce the risk of compromise. They are an important part of our layered, defense-in-depth approach to security. A SAW doesn\u2019t grant rights to any actual resources\u2014it provides a \u201csecure keyboard\u201d in which an administrator can connect to a secure server, which itself connects to the HRE.<\/p>\n A SAW is an administrative-and-productivity-device-in-one, designed and built by Microsoft for one of our most critical resources\u2014our administrators. Each administrator has a single device, a SAW, where they have a hosted virtual machine (VM) to perform their administrative duties and a corporate VM for productivity work like email, Microsoft Office products, and web browsing.<\/p>\n When working, administrators must keep secure devices with them, but they are responsible for them at all times. This requirement mandated that the secure device be portable. As a result, we developed a laptop that\u2019s a securely controlled and provisioned workstation. It\u2019s designed for managing valuable production systems and performing daily activities like email, document editing, and development work. The administrative partition in the SAW curbs credential-theft and credential-reuse scenarios by locking down the environment. The productivity partition is a VM with access like any other corporate device.<\/p>\n The SAW host is a restricted environment:<\/p>\n Again, the SAW controls are only as good as the environment that holds them, which means that the SAW isn\u2019t possible without the HRE. Maintaining adherence to SAW and HRE controls requires an ongoing operational investment, similar to any Infrastructure as a Service (IaaS). Our engineers code-review and code-sign all applications, scripts, tools, and any other software that operates or runs on top of the SAW. The administrator user has no ability to download new scripts, coding modules, or software outside of a formal software distribution system. Anything added to the SAW gets reviewed before it\u2019s allowed on the device.<\/p>\n As we onboard an internal team onto SAW, we work with them to ensure that their services and endpoints are accessible using a SAW device. We also help them integrate their processes with SAW services.<\/p>\n Once a team has adopted the new company standard of requiring administrators to use a SAW, we deploy the Microsoft Azure-based Conditional Access (CA) policy. As part of CA policy enforcement, administrators can\u2019t use their elevated privileges without a SAW. Between the time that an administrator places an order and receives the new SAW, we provide temporary access to a SAW device so they can still get their work done.<\/p>\n We ensure security at every step within our supply chain. That includes using a dedicated manufacturing line exclusive to SAWs, ensuring chain of custody from manufacturing to end-user validation. Since SAWs are built and configured for the specific user rather than pulling from existing inventory, the process is much different from how we provision standard corporate devices. The additional security controls in the SAW supply chain add complexity and can make scaling a challenge from the global-procurement perspective.<\/p>\n SAWs come with dedicated, security-aware support services from our Secure Admin Services (SAS) team. The SAS team is responsible for the HRE and the critical SAW devices\u2014providing around-the-clock role-service support to administrators.<\/p>\n The SAS team owns and supports a service portal that facilitates SAW ordering and fulfillment, role management for approved users, application and URL hosting, SAW assignment, and SAW reassignment. They\u2019re also available in a development operations (DevOps) model to assist the teams that are adopting SAWs.<\/p>\n As different organizations within Microsoft choose to adopt SAWs, the SAS team works to ensure they understand what they are signing up for. The team provides an overview of their support and service structure and the HRE\/SAW solution architecture, as illustrated in the graphic below.<\/p>\n Today, the SAS team provides support service to more than 40,000 administrators across the company. We have more work to do as we enforce SAW usage across all teams in the company and stretch into different roles and responsibilities.<\/p>\n The password-vaulting service allows passwords to be securely encrypted and stored for future retrieval. This eliminates the need for administrators to remember passwords, which has often resulted in passwords being written down, shared, and compromised.<\/p>\n SAS Password Vaulting is composed of two internal, custom services currently offered through our SAS team:<\/p>\n Password management is further enhanced by the service\u2019s capability to automatically generate and roll complex random passwords. This ensures that privileged accounts have high-strength passwords that are changed regularly and reduces the risk of credential theft.<\/p>\n We\u2019ve put administrative policies in place for privileged-account management. They\u2019re designed to protect the enterprise from risks associated with elevated administrative rights. Microsoft Digital reduces attack vectors with an assortment of security services, including SAS and Identity and Access Management, that enhance the security posture of the business. Especially important is the implementation of usage metrics for threat and vulnerability management. When a threat or vulnerability is detected, we work with our Cyber Defense Operations Center (CDOC<\/a>) team. Using a variety of monitoring systems through data and telemetry measures, we ensure that compliance and enforcement teams are notified immediately. Their engagement is key to keeping the ecosystem secure.<\/p>\n Least-privileged access paired with a just-in-time (JIT) entitlement system provides the least amount of access to administrators for the shortest period of time. A JIT entitlement system allows users to elevate their entitlements for limited periods of time to complete elevated-privilege and administrative duties. The elevated privileges normally last between four and eight hours.<\/p>\n JIT allows removal of users\u2019 persistent administrative access (via Active Directory Security Groups) and replaces those entitlements with the ability to elevate into roles on-demand and just-in-time.e used proper RBAC approaches with an emphasis on providing access only to what is absolutely required. We also implemented access controls to remove excess access (for example, Global Administrator or Domain Administrator privileges).<\/p>\n An example of how JIT is part of our overarching defense-in-depth strategy is a scenario in which an administrator\u2019s smartcard and PIN are stolen. Even with the physical card and the PIN, an attacker would have to successfully navigate a JIT workflow process before the account would have any access rights. In the three years this project has been going on, we have learned that an ongoing commitment and investment are critical to providing defense-in-depth protection in an ever-evolving work environment. We have learned a few things that could help other companies as they decide to better protect their administrators and, thus, their company assets:<\/p>\n As we stated before, there are no silver-bullet solutions when it comes to security. As part of our defense-in-depth approach to an ever-evolving threat landscape, there will always be new initiatives to drive.<\/p>\n Recently, we started exploring how to separate our administrators from our developers and using a different security approach for the developer roles. In general, developers require more flexibility than administrators.<\/p>\n There also continue to be many other security initiatives around device health, identity and access management, data loss protection, and corporate networking. We\u2019re also working on the continued maturity of our compliance and governance policies and procedures.<\/p>\n While it has taken us years to develop, implement, and refine our multitiered, defense-in-depth approach to security, there are some solutions that you can adopt now as you begin your journey toward improving the state of your organization\u2019s security:<\/p>\n Customers interested in adopting a defense-in-depth approach to increase their security posture might want to consider implementing Privileged Access Workstations<\/a> (PAW)<\/a>. PAWs are a key element of the Enhanced Security Administrative Environment (ESAE)<\/a> reference architecture deployed by the cybersecurity professional services teams at Microsoft to protect customers against cybersecurity attacks.<\/p>\n For more information about engaging Microsoft Services to deploy PAWs or ESAE for your environment, contact your Microsoft representative or visit the Cybersecurity Protection page<\/a>.<\/p>\n Over the last two years we\u2019ve had an outside security audit expert perform a cyber-essentials-plus certification process. In 2017, the security audit engineers couldn\u2019t run most of their baseline tests because the SAW was so locked down. They said it was the \u201cmost secure administrative-client audit they\u2019ve ever completed.\u201d They couldn\u2019t even conduct most of their tests with the SAW\u2019s baseline, locked configuration.<\/p>\n In 2018, the security audit engineer said: \u201cI had no chance; you have done everything right,\u201d and added, \u201cYou are so far beyond what any other company in the industry is doing.\u201d<\/p>\n Also, in 2018, our SAW project won a CSO50 Award, which recognizes security projects and initiatives that demonstrate outstanding business value and thought leadership. SAW was commended as an innovative practice and a core element of the network security strategy at Microsoft.<\/p>\n Ultimately, the certifications and awards help validate our defense-in-depth approach. We are building and deploying the correct solutions to support our ongoing commitment to securing Microsoft and our customers\u2019 and partners\u2019 information. It\u2019s a pleasure to see that solution recognized as a leader in the industry.[Editor\u2019s note: This content was written to highlight a particular event or moment in time. Although that moment has passed, we\u2019re republishing it here so you can see what our thinking and experience was like at the time.] <\/em><\/p>\n
Understanding defense-in-depth protection<\/h2>\n
Risk-based approach<\/h3>\n
Implementing the Protect the Administrators program<\/h2>\n
\n
Defining your corporate landscape<\/h3>\n
Refining roles to reduce attack surfaces<\/h3>\n
Defining roles<\/h4>\n
Using role-based controls to establish elevated-privilege roles<\/h4>\n
Performing role attestation<\/h4>\n
Implementing least-privileged access<\/h3>\n
\n
Creating a secure high-risk environment<\/h3>\n
Secure devices<\/h3>\n
\n
Provisioning the administrator<\/h4>\n
Supporting the administrator<\/h4>\n
Password vaulting<\/h3>\n
\n
Administrative policies<\/h3>\n
Just-in-time entitlement system<\/h3>\n
\n<\/p>\n
\n
What\u2019s next<\/h2>\n
Getting started<\/h2>\n
\n
Microsoft Services can help<\/h3>\n
Reaping the rewards<\/h2>\n
\n<\/p>\n
\n