I'm not going to help a ton since I'm a few years removed from being useful on the desktop, but where I work, we either don't allow that software or we make exceptions based on roles.
For software that just needs admin rights, we do whatever we can to say no to having it in our network. If we absolutely must, we do entertain the idea of hosting it on a virtual Windows desktop system and granting as-needed access to it or something. Thankfully this doesn't come up all that much and we have a robust virtual environment and we've successfully said no to software over the years for various reasons including being incompatible with our security posture. We also often get slightly involved in looking up better alternatives or...guiding...decisions away from problem tools. But there are roles that simply require it, the most notorious being software developers, particularly all the coding and compiling tools like Visual Studio. In that case, we inventory what they have, make sure we have a computer use policy in place that they sign, and allow them to be local admins. I also personally keep them in mind for being a bit more strict in auditing or watching their logs for weirdness, and we do have other defense in depth anyway (web filter, local ips, network ips, outbound fw denies, etc). Allowing local admin does compound problems with supporting those users. They install junk, screw things up easily, and so on. We make sure our developers know this, and in turn they actually do quite a bit of the management of their systems as opposed to relying entirely on our centralized deployment tools (e.g. altiris, vdi, sscm...) to install their stuff. Sort of the trade-off to make sure people can still do their jobs. Getting fancy very quickly leads into support problems. No one will ever anticipate what was built or how it was done, from the software vendor, related software, or support persons down the road. Sometimes being crazy and special and custom yields admirably tight security, but at a tradeoff of inefficient support down the road. I like things simple. :) On Sun, Jun 16, 2013 at 9:25 PM, Michael Salmon <[email protected]>wrote: > Hi guys, > Got a question I'd like to get some advice on. I support a Windows 7 > environment and we stripped the users of admin rights, however there are > some applications that still require admin rights to run. > For one user I tried setting him up with a 2nd account w/ admin rights so > he could Run As the program with it but he figured out that it works for > any software and abused it (yeah, I know.. big surprise). Another option > I've looked into is creating a shortcut to the program that uses the runas > /savecred for the default admin account to launch the program but then any > malicious program (or smart user) can launch most executables by using the > runas /savecred without needing to enter the admin password. While I do > believe this is still better then always running as admin, it's not the > best option. > How do others in their environments handle these situations? > One option that has been brought up is granting users admin rights and > using a white list software to prevent launching any programs that aren't > approved. I'm not sure how easy these are to work around or maintain as I > haven't tested any whitelisting software yet. > > Thanks guys! > BTW, PDC guys/girls did a great job hosting and presenting at Security-B > sides in RI! I had a great time, and a thank you to Mike Perez who provided > some great info for security noobs like me :) > > - Michael Salmon > > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com > On Sun, Jun 16, 2013 at 9:25 PM, Michael Salmon <[email protected]>wrote: > Hi guys, > Got a question I'd like to get some advice on. I support a Windows 7 > environment and we stripped the users of admin rights, however there are > some applications that still require admin rights to run. > For one user I tried setting him up with a 2nd account w/ admin rights so > he could Run As the program with it but he figured out that it works for > any software and abused it (yeah, I know.. big surprise). Another option > I've looked into is creating a shortcut to the program that uses the runas > /savecred for the default admin account to launch the program but then any > malicious program (or smart user) can launch most executables by using the > runas /savecred without needing to enter the admin password. While I do > believe this is still better then always running as admin, it's not the > best option. > How do others in their environments handle these situations? > One option that has been brought up is granting users admin rights and > using a white list software to prevent launching any programs that aren't > approved. I'm not sure how easy these are to work around or maintain as I > haven't tested any whitelisting software yet. > > Thanks guys! > BTW, PDC guys/girls did a great job hosting and presenting at Security-B > sides in RI! I had a great time, and a thank you to Mike Perez who provided > some great info for security noobs like me :) > > - Michael Salmon > > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com > On Sun, Jun 16, 2013 at 9:25 PM, Michael Salmon <[email protected]>wrote: > Hi guys, > Got a question I'd like to get some advice on. I support a Windows 7 > environment and we stripped the users of admin rights, however there are > some applications that still require admin rights to run. > For one user I tried setting him up with a 2nd account w/ admin rights so > he could Run As the program with it but he figured out that it works for > any software and abused it (yeah, I know.. big surprise). Another option > I've looked into is creating a shortcut to the program that uses the runas > /savecred for the default admin account to launch the program but then any > malicious program (or smart user) can launch most executables by using the > runas /savecred without needing to enter the admin password. While I do > believe this is still better then always running as admin, it's not the > best option. > How do others in their environments handle these situations? > One option that has been brought up is granting users admin rights and > using a white list software to prevent launching any programs that aren't > approved. I'm not sure how easy these are to work around or maintain as I > haven't tested any whitelisting software yet. > > Thanks guys! > BTW, PDC guys/girls did a great job hosting and presenting at Security-B > sides in RI! I had a great time, and a thank you to Mike Perez who provided > some great info for security noobs like me :) > > - Michael Salmon > > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com >
_______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
