DOCSLIB.ORG

Implementing Least Privilege in Windows 2000, Part I: Stand-Alone W2k

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Implementing Least Privilege in Windows 2000, Part I: Stand-Alone W2k 84-02-04 DATA SECURITY MANAGEMENT IMPLEMENTING LEAST PRIVILEGE IN WINDOWS 2000, PART I: STAND-ALONE W2K Roberta Bragg, CISSP INSIDE Groups; Default Groups; Implicit Groups; User Rights; Default Object Access — Object Permissions; Group Scope; Practical Implications; Best Practices The key to understanding how to apply least privilege lies in understand- ing four W2K concepts: 1. groups 2. user rights 3. object permissions 4. group scope The meaning of these concepts is often obscured by a discussion of W2K domains and Active Directory issues. To start with the basics, the discussion is divided into two parts. This article deals primarily with the PAYOFF IDEA implementation of least privilege on One of the most critical tenets of information sys- W2K systems that are not joined in a tem security is the principle of least privilege, that W2K domain. Another article, Part II, is, the application of a policy that provides each user of the system with the most restrictive set of will enlarge the discussion to include access and privileges that will still allow the user W2K systems that have been joined to get his or her job done. One can implement this in a W2K domain. Included in that principle in Windows 2000 as it protects access discussion will be additional features to system operation and to object access by re- of Active Directory (delegation of quiring authenticated system access, assign- ment of privileges, and granular assignment of authority, object permissions) that object permissions. The key to understanding can be used to further enhance the how to apply this principle lies in understanding process. four W2K concepts: (1) groups; (2) user rights; (3) object permissions; (4) group scope. Auerbach Publications © 2001 CRC Press LLC DATA SECURITY MANAGEMENT Information, except where noted, applies to Windows 2000 Profes- sional, Windows 2000 Server, or Windows 2000 Advanced Server com- puters. When these systems are not joined in a domain, they are often referred to as stand-alone not because they are unconnected from other information systems, but because access to their resources, and manage- ment of their processes is only assigned to local groups or accounts. Lo- cal groups and accounts exist only within the system’s local user database, a database that is present only on the local machine. Access to local resources and privileges on the system are granted to these local user and group accounts. GROUPS While user accounts can directly be assigned user rights and access to re- sources, the recommended practice in W2K is to place user accounts into groups and assign the groups rights and permissions. To foster this prac- tice, Windows 2000 comes preconfigured with default groups, each of which has a set of preassigned user rights. Default user accounts exist as well. New user and group accounts can be created, and group member- ship can be changed. Privileges and access permissions can be assigned to these new accounts and default groups can have their rights and per- missions removed. The wise designer of security on W2K systems will first consider default groups, then create groups that represent additional job functions, place user accounts in the appropriate groups, and assign privileges to the groups. In addition to explicit groups, implicit groups exist as well. Implicit group membership is determined by user state and is not under admin- istrative control. DEFAULT GROUPS To view the list of default users and groups: Windows 2000 Professional: 1. Click the Start button and select “Settings” 2. Select “Control panel” 3. Click the “Administrative Tools” icon 4. Select “Computer Management” 5. Navigate to and expand “Local Users and Groups” Two folders, one for Users and one for Groups, can be opened to see their respective lists. Double-clicking on a User or Group will allow one to view their property pages and determine group membership as well as other attributes. Default Users on Windows 2000 Professional, Windows 2000 Server, and Advanced Server are: IMPLEMENTING LEAST PRIVILEGE IN WINDOWS 2000, PART I: STAND-ALONE W2K • Administrator: all-powerful access and control of the local system. One can remove the Administrators privileges; however, one privi- lege will always remain: the ability to take ownership of objects. This account cannot be removed or disabled. • Guest: disabled by default, this account could allow unauthenticated access to the system. • TsInternetUser: this account is used by Windows 2000 Terminal Ser- vices and is only available on Server/Advanced Server. Default Groups are: • Administrators: all-powerful access and control of the local system • Backup operators: privileges to backup and restore data • Guests: access to resources as designated • Power users: users with more rights than normal users, but less than Administrators • Replicator: a special group with privileges to participate in file repli- cation with down-level (Windows NT 4.0) systems • Users: every user account becomes a member of this group Tip: For ease in administering and auditing stand-alone systems, one can place the “Administrative Tools” shortcut on the Start menu. To do so: 1. Right click on the Task bar and select “Properties” from the pop- up menu. 2. Select the “Advanced” tab. 3. Check the box “Display Administrative Tools.” 4. Click OK. Now the path will be: Start\Programs\Administrative Tools Each default group has predefined sets of user rights and specified de- fault access to system files and folders, and registry keys. IMPLICIT GROUPS Implicit groups are also assigned rights and access abilities on the sys- tem. Membership in implicit groups is determined by the activities of the user. Is the user sitting at the console having logged on using a local user account? They are automatically a member of the INTERACTIVE group. Is the user accessing shared resources across the network? Now DATA SECURITY MANAGEMENT they are members of the NETWORK group. No administrator can force membership in any of these groups, nor can an administrator remove a user from them. The administrator, can, however, assign implicit groups additional privileges and permissions on the system. Because a user’s actions determine group membership, administrators can indirectly in- clude or exclude membership by granting privileges and assigning per- missions to users and groups. For example, if you deny my account the right to “access this computer from the network,” then you have effec- tively denied me membership in the NETWORK implicit group. On the other hand, if you do not configure the system to “restrict anonymous access,” you are allowing membership in the group Everyone to anyone who can connect to the system, even if they do not have a W2K local account on the system. Implicit groups in Windows 2000 are: • Everyone: users that have achieved access to the system, whether by authentication or via anonymous access. • Authenticated user: users that have successfully authenticated to the system. • ANONYMOUS LOGON: users achieving logon via anonymous ac- count or access. • BATCH: the user has the “batch logon” right and is logged on. The batch logon right is rarely used in W2K. It would be necessary if an account was used by an application to logon and run a background process such as a bank reconciliation. • CREATOR OWNER: when a user creates an object in Windows 2000, that user becomes the CREATOR OWNER of that object. • CREATOR GROUP: the group to which the creator belongs. The abil- ity to assign this group privileges is useful in creating interoperability with UNIX systems. For an example, look to objects created by an Administrator; the Administrators group is considered always listed as object owner. • DIAL-UP: users who have accessed the computer via dial-up. • INTERACTIVE: users who are accessing resources while sitting at the computer console. • NETWORK: users accessing resources across networks. • SERVICE: accounts used to run a W2K service. • SYSTEM: the operating system itself. • TERMINAL SERVER USER: users accessing the system via terminal services. USER RIGHTS Access to Windows 2000 systems includes the ability to access objects such as files and registry keys and the privileges of performing actions. IMPLEMENTING LEAST PRIVILEGE IN WINDOWS 2000, PART I: STAND-ALONE W2K Access to objects is defined by granting permissions on these objects. Registry keys have default access permission assigned. If the systems has been installed on an NTFS partition, system files and folders have default access permissions predefined. Changes to these permissions sets, as well as the assignment of access permissions to new objects, is under ad- ministrative control. Permissions should be granted to groups, but may be assigned directly to an account. Privileges to perform actions is defined by user rights in Windows 2000. Default sets of user rights is assigned to default Windows 2000 groups, but can be modified. This is an important concept and its ulti- mate meaning is that all access, and thus the configuration of “least priv- ilege,” is under the control of system administrators. Every preassigned user right, except the right of the local Administrator account to take ownership of objects and thus regain privileges and rights removed or denied, can be changed. To repeat: Every user right assignment can be modified. This means that one cannot totally restrict administrative ac- counts; after all, someone must be able to administer the system, but it does mean one can alter their rights and privileges of access on a system. Typically, one will accept the default sets of user rights, and perhaps ex- pand them by creating user groups to fit one’s security model, and grant- ing these user defined groups appropriate privileges and object access. A good example of restricting default user rights (and thus further defining “least privilege”) might be to remove the “restore files and directories” right from the local backup group, and creating a new group called “Lo- cal Restore” and granting that group the user right to restore files and di- rectories.
Load more

Recommended publications
  • Security in Ordinary Operating Systems
    39 C H A P T E R 4 Security in Ordinary Operating Systems In considering the requirements of a secure operating system,it is worth considering how far ordinary operating systems are from achieving these requirements. In this chapter, we examine the UNIX and Windows operating systems and show why they are fundamentally not secure operating systems. We first examine the history these systems, briefly describe their protection systems, then we show, using the requirements of a secure operating system defined in Chapter 2, why ordinary operating systems are inherently insecure. Finally, we examine common vulnerabilities in these systems to show the need for secure operating systems and the types of threats that they will have to overcome. 4.1 SYSTEM HISTORIES 4.1.1 UNIX HISTORY UNIX is a multiuser operating system developed by Dennis Ritchie and Ken Thompson at AT&T Bell Labs [266]. UNIX started as a small project to build an operating system to play a game on an available PDP-7 computer. However, UNIX grew over the next 10 to 15 years into a system with considerable mindshare, such that a variety of commercial UNIX efforts were launched. The lack of coherence in these efforts may have limited the market penetration of UNIX, but many vendors, even Microsoft, had their own versions. UNIX remains a significant operating system today, embodied in many systems, such as Linux, Sun Solaris, IBM AIX, the various BSD systems, etc. Recall from Chapter 3 that Bell Labs was a member of the Multics consortium. However, Bell Labs dropped out of the Multics project in 1969, primarily due to delays in the project.
    [Show full text]
  • User-Driven Access Control: Rethinking Permission Granting in Modern Operating Systems
    This paper appears at the 33rd IEEE Symposium on Security and Privacy (Oakland 2012). User-Driven Access Control: Rethinking Permission Granting in Modern Operating Systems Franziska Roesner, Tadayoshi Kohno Alexander Moshchuk, Bryan Parno, Helen J. Wang Crispin Cowan ffranzi, [email protected] falexmos, parno, [email protected] [email protected] University of Washington Microsoft Research Microsoft Abstract— Modern client platforms, such as iOS, Android, Thus, a pressing open problem is how to allow users to Windows Phone, Windows 8, and web browsers, run each ap- grant applications access to user-owned resources: privacy- plication in an isolated environment with limited privileges. A and cost-sensitive devices and sensors (e.g., the camera, GPS, pressing open problem in such systems is how to allow users to grant applications access to user-owned resources, e.g., to or SMS), system services and settings (e.g., the contact list privacy- and cost-sensitive devices like the camera or to user or clipboard), and user content stored with various applica- data residing in other applications. A key challenge is to en- tions (e.g., photos or documents). To address this problem, able such access in a way that is non-disruptive to users while we advocate user-driven access control, whereby the system still maintaining least-privilege restrictions on applications. captures user intent via authentic user actions in the context In this paper, we take the approach of user-driven access con- trol, whereby permission granting is built into existing user ac- of applications. Prior work [22, 32, 33] applied this principle tions in the context of an application, rather than added as an largely in the context of least-privilege file picking, where an afterthought via manifests or system prompts.
    [Show full text]
  • Download the Ethical Hacker's Guide to System Hacking
    The Ethical Hacker's Guide To System Hacking Attacker acquires information through techniques such as foot printing, scanning and enumeration to hack the target system. 1 Footprinting Scanning Enumeration Module Vulnerability Analysis It is the process of accumulating data Vulnerability Assessment is an This is a procedure for identifying This is a method of intrusive probing, Footprinting Scanning System Hacking regarding a specific network environment. active hosts, open ports, and unnecessary through which attackers gather examination of the ability of a system or In this phase, the attacker creates a profile services enabled on ports. Attackers use information such as network user lists, application, including current security CEH concepts of the target organization, obtaining different types of scanning, such as port routing tables, security flaws, and procedures, and controls to with stand 2 information such as its IP address range, scanning network scanning, and simple network protocol data (SNMP) assault. Attackers perform this analysis Methodology Vulnerability namespace and employees. Enumeration vulnerability, scanning of target networks data. to identify security loopholes, in the target Analysis Footprinting eases the process of or systems which help in identifying organization’s network, communication system hacking by revealing its possible vulnerabilities. infrastructure, and end systems. vulnerabilities 3 Clearing Logs Maintaining Access Gaining Access Hacking Stage Escalating Privileges Hacking Stage Gaining Access It involves gaining access to To maintain future system access, After gaining access to the target low-privileged user accounts by To acquire the rights of To bypass access CEH Hacking attackers attempt to avoid recognition system, attackers work to maintain cracking passwords through Goal another user or Goal controls to gain System Hacking by legitimate system users.
    [Show full text]
  • Proceedings of the 12Th USENIX Security Symposium
    USENIX Association Proceedings of the 12th USENIX Security Symposium Washington, D.C., USA August 4–8, 2003 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2003 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. Preventing Privilege Escalation Niels Provos Markus Friedl Peter Honeyman CITI, University of Michigan GeNUA CITI, University of Michigan Abstract gain extra privilege after successful authentication lim- its the degree of escalation because the user is already Many operating system services require special priv- authorized to hold some privilege. On the other hand, ilege to execute their tasks. A programming error in a a remote adversary gaining superuser privilege with no privileged service opens the door to system compromise authentication presents a greater degree of escalation. in the form of unauthorized acquisition of privileges. In For services that are part of the critical Internet the worst case, a remote attacker may obtain superuser infrastructure is it particularly important to protect privileges. In this paper, we discuss the methodology against programming errors. Sometimes these services and design of privilege separation, a generic approach need to retain special privilege throughout their life- that lets parts of an application run with different levels time. For example, in SSH, the SSH daemon needs to of privilege.
    [Show full text]
  • Configuration Recommendations of a Gnu/Linux System
    .. CONFIGURATION RECOMMENDATIONS OF A GNU/LINUX SYSTEM ANSSI GUIDELINES ANSSI-BP-028-EN 22/02/2019 TARGETED AUDIENCE: Developers Administrators IT security managers IT managers Users . .. Information Warning This document, written by ANSSI, the French National Information Security Agency, presents the “Configuration recommendations of a GNU/LINUX system”. It is freely avail- able at www.ssi.gouv.fr/en/. It is an original creation from ANSSI and it is placed under the “Open Licence v2.0” published by the Etalab mission [12]. According to the Open Licence v2.0, this guide can be freely reused, subject to mentionning its paternity (source and date of last update). Reuse means the right to communicate, distribute, redistribute, publish, transmit, reproduce, copy, adapt, modify, extract, transform and use, including for commercial purposes These recommendations are provided as is and are related to threats known at the publi- cation time. Considering the information systems diversity, ANSSI cannot guarantee direct application of these recommendations on targeted information systems. Applying the fol- lowing recommendations shall be, at first, validated by IT administrators and/or IT security managers. This document is a courtesy translation of the initial French document “Recommandations de configuration d’un système GNU/Linux”, available at www.ssi.gouv.fr. In case of con- .flicts between these two documents, the latter is considered as the only reference. Document changelog: VERSION DATE CHANGELOG 1.2 22/02/2019 English version based on a courtesy translation provided by Red Hat CONFIGURATION RECOMMENDATIONS OF A GNU/LINUX SYSTEM – 1 . Contents 1 Glossary 4 2 Preamble 5 2.1 Foreword ..........................................
    [Show full text]
  • Technical Analysis of Access Token Theft and Manipulation REPORT
    REPORT Technical Analysis of Access Token Theft and Manipulation REPORT Table of Contents 3 Introduction 11 Other SYSTEM Level Processes 5 Access Token Creation and User Account Control 14 Coverage 7 Access Token Manipulation 14 MITRE ATT&CK 15 Detecting Access Token Manipulation Attacks 8 Looking at the Code: Technique 1: CreateProcessWithTokenW 15 YARA Rule 9 Looking at the Code: Technique 2: 16 Conclusion ImpersonateLoggedOnUser 16 About the Author 9 Looking at the Code: Technique 3: 16 Chintan Shah CreateProcessAsUser 17 About McAfee 10 Looking at the Code: Technique 4: SetThreadToken 17 McAfee ATR ResumeThread 2 Technical Analysis of Access Token Theft and Manipulation REPORT Technical Analysis of Access Token Theft and Manipulation Introduction When a user is authenticated to Windows, it creates Author Privilege escalation is one of the primary tasks malware a logon session for the user and returns the user SID must perform to be able to access Windows resources (Security Identifier) and SID of the groups to which the This report was researched and written by: that require higher privileges, perform privileged actions user belongs, which is eventually used to control access (like executing privileged commands, etc.) on the system, to various system resources. Local Security Authority ■ Chintan Shah and move laterally inside the network to access and (LSA) creates the access token for the user. This infect other systems. Access token manipulation attacks access token is primarily a kernel object that describes Subscribe to receive threat are massively adopted and executed by malware and the security context of the process or the thread, information. advanced persistent threats to gain higher privileges on as described here.
    [Show full text]
  • Do Windows Users Follow the Principle of Least Privilege? Investigating User Account Control Practices
    Do Windows Users Follow the Principle of Least Privilege? Investigating User Account Control Practices Sara Motiee, Kirstie Hawkey, Konstantin Beznosov Laboratory for Education and Research in Secure Systems Engineering Department of Electrical and Computer Engineering, University of British Columbia Vancouver, Canada {motiee,hawkey,beznosov}@ece.ubc.ca ABSTRACT subject in a system be granted the most restrictive set of The principle of least privilege requires that users and their privileges possible for performing the task at hand. One practical implementation of PLP in operating systems is a programs be granted the most restrictive set of privileges 1 possible to perform required tasks in order to limit the dam- \least-privilege user account" (LUA), which requires users ages caused by security incidents. Low-privileged user ac- to use accounts with as few privileges as possible for day-to- counts (LUA) and user account control (UAC) in Windows day work on PCs [17]. To implement this approach, oper- Vista and Windows 7 are two practical implementations of ating system designers have developed various types of user this principle. To be successful, however, users must apply accounts and advise end users to employ low-privilege ac- due diligence, use appropriate accounts, and respond cor- counts for their daily tasks [17]. By following this approach, rectly to UAC prompts. With a user study and contextual users will be better protected from malware, security at- interviews, we investigated the motives, understanding, be- tacks, accidental or intentional modifications to system con- haviour, and challenges users face when working with user figuration, and unauthorized access to confidential data.
    [Show full text]
  • Real Operating Systems Lecture #12
    Real Operating Systems Lecture #12 Department of Computer Science and Technology University of Bedfordshire Written by David Goodwin, based on the lecture series of Dayou Li and the book Understanding Operating Systems 4thed. by I.M.Flynn and A.McIver McHoes (2006). Operating Systems, 2012 bg=white Real Operating Outline Systems Introduction Introduction DOS DOS Windows Windows Unix & Linux Unix & Linux Memory Management DOS Memory Management Windows DOS Linux Process Windows Management Linux DOS Windows Linux Process Management DOS Windows Linux bg=white Real Operating INTRODUCTION TO DIFFERENT Systems O/Ss Introduction DOS Windows Unix & Linux Memory Management DOS I Three typical operating systems Windows I Disk operating system (DOS) Linux I Windows Process Management I Unix/Linux DOS Windows Linux bg=white Real Operating DOS Systems Introduction I History DOS Windows I In 1980, IBM looked for an operating system for its Unix & Linux soon-to-be-released 6-bit personal computers Memory Management I Digital Research offered CP/M-86 DOS I Softech offered P-System Windows I MS Linux I MS also looked for OS for its 16-bit computers Process Management I Seattle Computer Products offered 86-DOS DOS I MS bought it and renamed it MS-DOS Windows Linux I IBM chose MS-DOS in 1981 and called it PC-DOS I MS-DOS evolved from v 1.0 to v 6.22 from 1981 to 1994 bg=white Real Operating DOS Systems I Features Introduction I Single user, stand-alone DOS desktop Windows I Command-line Unix & Linux I Commands are based on Memory words Management DOS I Examples
    [Show full text]
  • Towards Least Privilege Principle: Limiting Unintended Accesses in Software Systems
    Towards Least Privilege Principle: Limiting Unintended Accesses in Software Systems by Beng Heng Ng A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Computer Science and Engineering) in The University of Michigan 2013 Doctoral Committee: Professor Atul Prakash, Chair Professor Kang G. Shin Associate Professor Vineet R. Kamat Associate Professor Zijiang James Yang c Beng Heng Ng 2013 All Rights Reserved For my wife, Haoyi, and daughter, Reann. ii ACKNOWLEDGEMENTS The journey towards writing this thesis had not been an easy one, and I will forever be indebted to the kind people around me for their guidance and support. This thesis would not have materialize without the unrelenting support, enormous patience, and encouragement of my advisor, Prof. Atul Prakash. He has taught me the importance of rigorous research methodologies, critical thinking, as well as the need to always keep an open mind. His advice was not limited to science, but also included life, especially during one of the most challenging periods in my life. I am also extremely grateful to Prof. Shin, Prof. Kamat, and Prof. Yang, for their invaluable suggestions, perspectives and insights, which have helped shape this thesis. I also thank my previous and current colleagues, Billy Lau, Hu Xin, Alex Crowell, Earlence Fernandes, and Ajit Aluri, for the numerous intense and thought-provoking discussions. I gratefully acknowledge the funding provided by the Government of Singapore, thus allowing me to focus on my research that leads to this thesis. Above all, I would like to thank my wife, Hao Yi, for putting her dreams on hold so that I can go after mine.
    [Show full text]
  • Capability-Based Access Control
    Lecture Notes (Syracuse University) Capability: 1 Capability-Based Access Control 1 An Analogy: Bank Analogy We would like to use an example to illustrate the need for capabilities. In the following bank example, we will discuss two access control mechanisms: access control list (ACL) and capability. We will compare the pros and cons of these two different mechanisms. Example: Alice wishes to keep all of her valuables in three safe deposit boxes in the bank. Occasionally, she would like one or more trustworthy friends to make deposits or withdrawals for her. There are two ways that the bank can control access to the box. • The bank maintains a list of people authorized to access each box. • The bank issues Carla one or more keys to each of the safe deposit boxes. • The ACL Approach – Authentication: The bank must authenticate. – Bank’s involvement: The bank must (i) store the list, (ii) verify users. – Forging access right: The bank must safeguard the list. – Add a new person: The owner must visit the bank. – Delegation: A friend cannot extend his or her privilege to someone else. – Revocation: If a friend becomes untrustworthy, the owner can remove his/her name. • Capability Approach – Authentication: The bank does not need to authenticate. – Bank’s involvement: The bank need not be involved in any transactions – Forging access right: The key cannot be forged – Adding a new person: The owner can give the key to other people – Delegation: A friend can extend his or her privilege to someone else. – Revocation: The owner can ask for the key back, but it may not be possible to know whether or not the friend has made a copy.
    [Show full text]
  • Practical Techniques to Obviate Setuid-To-Root Binaries Bhushan Jain, Chia-Che Tsai, Jitin John, and Donald E
    Practical Techniques to Obviate Setuid-to-Root Binaries Bhushan Jain, Chia-Che Tsai, Jitin John, and Donald E. Porter Stony Brook University fbpjain, chitsai, jijjohn, [email protected] Abstract Net lines of code de-privileged. 12,717 Percentage of deployed Ubuntu and Debian systems that can 89.5% Trusted, setuid-to-root binaries have been a substantial, eliminate the setuid bit. long-lived source of privilege escalation vulnerabilities on Historical exploits that would be unprivileged on Protego. 40/40 Unix systems. Prior work on limiting privilege escalation Performance overheads ≤7.4% has only considered privilege from the perspective of the ad- System calls changed 8 ministrator, neglecting the perspective of regular users—the Table 1. Summary of results. primary reason for having setuid-to-root binaries. The paper presents a study of the current state of setuid- to-root binaries on Linux, focusing on the 28 most com- vice without involving a human administrator. Because the monly deployed setuid binaries in the Debian and Ubuntu mount binary must issue the mount() system call, which distributions. This study reveals several points where Linux requires root privilege (or the CAP SYS ADMIN capability), kernel policies and abstractions are a poor fit for the policies the mount binary is inadvertently empowered to issue many desired by the administrator, and root privilege is used to more privileged system calls. For instance, if an attacker can create point solutions. The majority of these point solutions exploit an input parsing bug in mount, she might be able to address 8 system calls that require administrator privilege, change the root user’s password, install a rootkit, or replace but also export functionality required by unprivileged users.
    [Show full text]
  • A Guide to Endpoint Privilege Management
    WHITE PAPER A GUIDE TO ENDPOINT PRIVILEGE MANAGEMENT Learn about least privilege and discover the business benefits SYNOPSIS BeyondTrust is the worldwide leader in Privileged Access In this whitepaper you will learn what endpoint privilege management is and how an effective approach significantly enhances an organization’s security against rising cybercrime. We cover the origins of the least privilege concept, the benefits of application control, the current cyber threat landscape and how endpoint privilege management works to combat this seamlessly and with minimal disruption to user productivity. We will also take a closer look at deployment offerings, including both on-premise and SaaS (Cloud) - providing you with a comprehensive understanding of the benefits and ease of rolling out an EPM solution in your organization. TABLE OF CONTENTS 1 Understanding the Cyber Security Landscape 3 2 The 'Least Privilege' Concept 5 3 What is Endpoint Privilege Management? 7 4 Leveraging EPM from the Cloud (SaaS) 11 5 Introducing Endpoint Privilege Management by BeyondTrust 12 6 Additional Benefits of Endpoint Privilege Management 14 7 How to Deploy an Endpoint Privilege Management Solution 15 8 Summary 16 9 Next Steps & Resources 16 Microsoft Vulnerabilities Report 2020 1 To better understand the role endpoint privilege management plays in the wider security landscape, we must first understand the current cybersecurity climate. Before Understanding we delve into how it works and what the benefits are, let’s look at some of the most the Cyber recent and credible industry research in order to paint an accurate picture of the Security landscape in 2019 and beyond. Landscape McAfee Labs In its December 2018 Threat Report, McAfee Labs identified 63 million new malware samples – a record high.1 As a result, the total count in their sample database has now surpassed 837 million.
    [Show full text]