[PDF] Do Windows Users Follow the Principle of Least Privilege





Previous PDF Next PDF



RECOMMANDATIONS POUR LA MISE EN PLACE DE

14-Dec-2017 Le principe de moindre privilège va de pair avec l'idée de séparation des privilèges. Comme présen- té en préambule du document réduire les ...



Principe de moindre privilège : quest-ce que ça mange en hiver et

Le principe de moindre privilège (connu sous l'abréviation POLP en anglais) est une politique selon laquelle les utilisateurs finaux ne bénéficient que des 



Principe de moindre privilège

Avant que l'élévation des privilèges ne soit effectuée Windows Server 2008/2008 R2 basculent par défaut la fenêtre de confirmation demandant cette élévation de 



Le principe du moindre privilège appliqué aux systèmes Windows

07-Feb-2005 Le principe du moindre privilège appliqué aux systèmes Windows. Jean-Baptiste Marchand. <Jean-Baptiste.Marchand@hsc.fr> ...



PRIVILEGE MANAGEMENT FOR WINDOWS SERVERS

BeyondTrust Privilege Management for Windows Servers réduit le risque d'utilisation abusive Principe du moindre privilège : élevez les privilèges admin.



Do Windows Users Follow the Principle of Least Privilege

16-Jul-2010 While low-privilege user accounts enhance security they have not been widely adopted. Indeed



Le guide du RSSI pour un accès Zero Trust efficace

24-Aug-2021 la fourniture d'un accès avec privilège moindre. D'où un nouveau modèle d'accès le ZTA (zero trust access) ou.



Principes de Sécurité et de Protection des Données pour lentité IBM

18-Dec-2017 IBM limite l'accès logique aux applications et aux bases de données au personnel autorisé dont la fonction exige l'accès. 2.2. Moindre Privilège.



Zscaler

tout en appliquant l'accès sur la base du moindre privilège. • Arrêter les adversaires les plus sophistiqués. La protection des applications privées 



Note technique Recommandations de configuration dun système

08-Oct-2015 3.2 Principe de moindre privilège . ... uniquement accessible à quelques personnes pourra demander un niveau de sécurité moindre.

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

The principle of least privilege requires that users and their programs be granted the most restrictive set of privileges possible to perform required tasks in order to limit the dam- ages caused by security incidents. Low-privileged user ac- counts (LUA) and user account control (UAC) in Windows Vista and Windows 7 are two practical implementations of this principle. To be successful, however, users must apply due diligence, use appropriate accounts, and respond cor- rectly to UAC prompts. With a user study and contextual interviews, we investigated the motives, understanding, be- haviour, and challenges users face when working with user accounts and the UAC. Our results show that 69% of par- ticipants did not apply the UAC approach correctly. All 45 participants used an administrator user account, and 91% were not aware of the benets of low-privilege user accounts or the risks of high-privilege ones. Their knowledge and ex- perience were limited to the restricted rights of low-privilege accounts. Based on our ndings, we oer recommendations to improve the UAC and LUA approaches.

Categories and Subject Descriptors

H.5.2 [Information Interfaces and Presentation]: User Interfaces|Evaluation/Methodology; D.4.6 [Software]: Ac- cess Controls|Invasive Software

General Terms

Human Factors, Security

Keywords

Usable security, least privilege principle, least privilege user account, user account control

1. INTRODUCTION

To limit damages from security breaches, the \principle of least privilege" [16], or PLP for short, requires that each Copyright is held by the author/owner. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee. Symposium on Usable Privacy and Security (SOUPS)2010, July 14-16,

2010, Redmond, WA USA

.subject in a system be granted the most restrictive set of privileges possible for performing the task at hand. One practical implementation of PLP in operating systems is a \least-privilege user account" (LUA),

1which requires users

to use accounts with as few privileges as possible for day-to- day work on PCs [17]. To implement this approach, oper- ating system designers have developed various types of user accounts and advise end users to employ low-privilege ac- counts for their daily tasks [17]. By following this approach, users will be better protected from malware, security at- tacks, accidental or intentional modications to system con- guration, and unauthorized access to condential data. While low-privilege user accounts enhance security, they have not been widely adopted. Indeed, during a Microsoft Financial Analyst Meeting in 2005, it was estimated that

85% of PC users performed their daily tasks using adminis-

trator accounts [11]. One reason for the lack of LUA popu- larity is that many simple tasks (e.g., changing the system time when traveling, installing an application) can only be done from an account with administrative privileges (\ad- min account" for short) [23]. It appears that users often choose the convenience of working with administrative priv- ileges over the reduction in risks associated with security breaches. Even though there is anecdotal evidence suggest- ing that mainstream operating systems support users poorly in following the PLP, there has been no published empirical data that could inform researchers and practitioners on the actual use of LUA and related mechanisms by users. The overarching goal of our research is to investigate how well mainstream operating systems for personal computers support users in following the PLP, and what can be done to improve such support. Our particular objectives are to determine (1) how well users are aided by the technology to follow this principle, (2) what challenges they face, (3) what factors motivate their behaviour, and (4) what are the areas of potential failure for current PLP mechanisms. For the initial study which we report in this paper, we nar- rowed the scope of our research to Windows Vista and Win- dows 7. In addition to LUA, Windows Vista introduced user account control (UAC) [23], which was intended to make the use of LUAs more convenient and therefore reduce incen- tives for violating PLP. With UAC, all users, including local administrators, can work with non-administrative privileges when such privileges are not necessary. A UAC prompt is raised when one of the user's processes requires adminis-1 Since LUAs may not necessarily beleastprivileged, we referto them as \low-privilege user accounts". 1 trative privileges (e.g., when installing software or changing system settings). UAC was revised in Windows 7 to reduce the number of prompts by default and to allow users to cus- tomize which prompts they receive. If UAC is disabled, 2the type of user account determines whether the PLP is followed (in case of a non-admin account) or not (in case of an admin account). However, if UAC is enabled on a user's system, it is not critical what type of user account is in use; as long as the user responds to UAC prompts correctly, the PLP is followed. Given this interdependency between LUA and UAC and the critical role of the two in the support for the PLP, we studied the behaviour of users in employing LUA as well as in responding to UAC prompts. To this end, we conducted a laboratory study, followed by contextual interviews. We recruited 30 Windows Vista and

15 Windows 7 users in order to observe any changes in their

behaviour according to the dierent UAC implementations on these Windows platforms. None of the demographics of our WV and W7 participants were statistically signicantly dierent, except for the years of experience with the oper- ating system. The participants had a wide range of educa- tional levels (from high school to Masters) and the 16 (out of 45) non-student participants had a variety of occupations. To maintain ecological validity, we asked all participants to perform study tasks on their Windows laptops. It was perhaps shocking, but not surprising, to nd every single participant performing day-to-day activities on own their laptop using an admin account. To better understand the factors aecting the use of LUA approach, we asked the study participants to complete a user account creation task, and we probed their knowledge about LUA. Although most created an appropriate low-privilege user account in the study task, participants were not motivated to employ a low-privilege account for their own daily computer usage. Furthermore, 91% of participants did not understand the security risks of high-privilege accounts or the benets of low-privilege ones. In addition to a lack of awareness of security risks, prior experience with the inconvenience of low-privilege user accounts in dierent contexts of prior dis- couraged participants from using such accounts. To investigate the use of the UAC approach, we asked participants to complete a set of tasks that raised legitimate and fake UAC prompts to observe their response behaviour. Our results show that at least 68% of participants did not use UAC approach correctly. These were participants who either disabled UAC (20%) or consented

3to a fake random,

i.e., not correlated with their current action, UAC prompt (49%). Interestingly, most of these participants (90%) did not have a correct understanding of the purpose of UAC prompts. On the other hand, those participants who had a partial understanding of UAC did not consent to the fake random prompt. It was not, however, the case for another fake prompt that was triggered as the result of participants' action during installation: all but 2 participants consented to both the fake and real UAC prompts raised during this task. This result suggests that when users initiate an action that might require admin privileges, they do not respond correctly to the subsequent UAC prompts. Based on our ndings, we oer several recommendations. Operating system developers should communicate the pur-2

UAC prompts can be disabled by the user.

3We use the term \consent" to indicate that the user con-sents to privilege elevation asked by UAC prompt.pose and benets of both UAC and LUA to users through

the interface itself, rather than only through the technical documentation from the OS vendor. Furthermore, either users should be made aware of the the distinction between UAC and other security-related mechanisms (e.g., personal rewall, anti-virus software), or UAC should be integrated with the other mechanisms. In addition to the admin ac- count created upon installation of the OS, users should be provided with an initial, default, low-privilege user account and be encouraged to use it for their daily work. How- ever, to ensure users continue following LUA, users must be able to conveniently apply modications on their PCs from within that low-privilege account. Furthermore, UAC prompts should be raised consistently, in selective and lim- ited situations so that users do not ignore them due to habit- uation. These prompts should communicate enough infor- mation about their purpose and functionality so that users can respond correctly. In the remainder of the paper, we rst discuss related work and background information about the mechanisms of applying PLP in Windows Vista and 7. We then describe the methodology of our study and its results in Sections 3 and 4, respectively. Section 5 provides a discussion of our results, as well as recommendations for applying PLP. We discuss the limitations of our study and outline future work in Section 6 and conclude the paper in Section 7.

2. BACKGROUND AND RELATED WORK

The aim of our research is to investigate whether users follow the PLP and how well the technology supports them in following this principle. We rst present related work on applying this principle. We then provide background about the UAC approach of Windows Vista and 7. As the UAC approach is based on raising warning messages, related work on warning messages is also discussed brie y.

2.1 The principle of least privilege

Dierent mechanisms have been implemented for apply- ing the PLP. One main category of mechanisms is the user account model oered by various operating systems. There are various types of user accounts with dierent privileges. In Unix-style operating systems, the root account has full privileges, while a non-root or basic account has limited priv- ileges. It is considered bad practice to use the root account for daily use, as simple typographical errors in commands can cause major damage to the system [12, 5]. In some Linux distributions (e.g., Ubuntu), there are three user ac- count types: root, admin, and basic. The initial user account created is an admin account that has fewer privileges than root, but can perform most administrative tasks. If a task requires root privileges, the user can use thesudocommand and enter a password to elevate her privileges. The basic user account has low privileges [13]. In Mac OS X, the root account is disabled and there is a default admin account created during the OS installation or activation. While Apple advises that this account be reserved for making changes to the system and installing system-wide applications [7], it is the only account created during the OS installation and the user has an option of con- guring her machine to log into this account automatically (i.e., without entering a password). Early Microsoft Windows operating systems did not have the concept of dierent user accounts on the same machine. 2 In NT and later versions of Windows, there are two types of user accounts:administratorandnormal(standard). In Windows 2000, XP Professional, and Server 2003, there is also a \power user" account type that has more permissions than a normal account, but does not have some admin per- missions. Microsoft advises users to use low-privilege user accounts for their daily computer use and recommends that admin and power user accounts only be used by trustworthy and knowledgeable users [17]. However, in all versions of Windows, all user accounts are created as admin by default; and users continued to use admin accounts on their systems. Moreover, using non-admin accounts inconvenienced users as many simple tasks (e.g., changing the system time) could only be done with an admin account [23]. Other mechanisms external to the operating system have been developed for applying the PLP. One approach is Sand- boxing [9], which provides a tightly-controlled set of re- sources for a program to run. However, the rules for speci- fying resources are static and adding privileges to a running program is dicult. Another approach is asking the user to conrm the permissions for an application when it is started or during run time. Some Java Web Start applications follow this approach [6]. Moreover, two packages have been devel- oped for Microsoft Windows for applying the PLP. The rst, CapDesk [20], is a distributed le browser and application launcher that was developed to reduce the threat of viruses and trojan horses for everyday users of the Web. It allows users to browse les and open them with the associated ap- plication; opening a le in CapDesk rst launches a caplet, which only has the authority to edit the le that was double- clicked. A security evaluation found the approach to have merit, but no user evaluation was conducted. The second, Polaris [19] was developed by HP Labs for Windows XP; its design was based on CapDesk. Polaris launches each appli- cation without the authority to access any user les. When a user opens a le via double clicking or the le chooser di- alog box, Polaris grants the application access to that le. There were plans to install Polaris on consumer PCs that HP ships, but the current status of these plans are unclear. We are unaware of any study directly evaluating technol- ogy support for the PLP; however, there has been some work looking at user account models for shared home comput- ers. Egelman et al. [2] presented and evaluated a new user account model called Family Accounts, which provides a shared family account as well as personal accounts. Switch- ing between accounts happens quickly and does not close running applications. Sharing information is easier usingquotesdbs_dbs47.pdfusesText_47
[PDF] moine cistercien

[PDF] moine copiste enluminure

[PDF] moines copistes histoire

[PDF] moinillon au quotidien

[PDF] mois et jour en espagnol

[PDF] mois sans tabac 2017

[PDF] mois sans tabac kit 2017

[PDF] mois sans tabac kit gratuit 2017

[PDF] mois sans tabac kit pharmacie

[PDF] mois sans tabac kit pharmacie 2017

[PDF] mois sans tabac tabac info service

[PDF] moise entre dieu et les hommes fiche de lecture

[PDF] moise entre dieu et les hommes questionnaire

[PDF] moïse michel ange

[PDF] moitié et fraction