I’m in the IT security department of a decent-sized company. Our environment includes a large number of kiosk workstations – the Windows desktop is always up, but you need to supply credentials to get into applications. Currently, we’re not doing a very good job of locking down those workstations. The users pretty much have the run of the PC (no admin rights, but they can get to the whole Start Menu, command line, etc). I’m getting ready to embark on a crusade to get the desktop guys to control these PCs better, through GPOs and so on.
I have a meeting next week about this, and I don’t want to come out of the toilet with just my dick in my hands*. I’d like to be able to use some kind of authoritative publication to support my recommendations. I’ve been looking without much success for some kind of “Recommendations for Securing Kiosk Workstations” kind of document, maybe from Microsoft, NIST, SANS, or some other heavyweight organization. I think I can make a pretty good case on my own, but I’m still new in this position, and I to be able to demonstrate that I’m not just making this shit up. If I can say, “I think the NIST recommendation about XYZ is applicable because…”, that will help me deflect the pushback I’m expecting from the desktop guys.
Can anyone recommend a source that might help me out?
*Sorry, Godfather moment.
Well I don’t have any cites but I can tell you how the State of California, Department of General Services does it. Our kiosk workstations are isolated off the network. The user login is something very generic and they have no admin rights. We don’t lock down anything on the start menu or take off the command shortcut but then again still no admin rights. Users cannot access the control panal or system properties.
Are you trying to set up kiosks or “thin client” workstations?
Check out www.kiosks.org - this is a kiosk trade association, and somewhere in there, you should be able to find info specific to your needs.
Nothing authoritative here, but have a look at Windows Embedded. This is the version of choice for runing things out in public like ATMs, movie ticket vendors and kiosks.
There’s also client software such as Kioware, SKOS, Provisio and many more that can simplify administration and control.
I might be hazy on the distinction. I’m envisioning a wks with a very basic Windows desktop, probably including the Taskbar, but otherwise just shortcuts to the applications the users need. I think the taskbar will be helpful because the users will often have more than one application open at a time, and they’ll want to switch back and forth. More people are used to clicking around on the taskbar rather than using ALT-TAB, probably. The wks probably won’t need any Office apps, and I’m thinking we want to take away access to C:, USB ports, optical drives, etc. They’ll have internet access, but we’ll want to make sure they can’t change any configuration. So… sound more like a kiosk or a thin client wks?
As background, I’m in a healthcare setting. These are workstastions in a clinical area, where the clinicans don’t want to wait for the desktop to come around just so they can log into the EMR. So, we’re not forcing them all to log into Windows, but they are logging in to the apps where the patient dats is. Problem is, they might write a Word doc with patient data and save it to the Desktop, or someone might start poking around in stuff they don’t need to be poking around in, etc.
If you’re using Citrix on the back-end, it would be easy enough to give access to Word and have documents saved centrally in addition to whatever other applications they need.
You can put Internet Explorer in the Startup folder with the -k (for kiosk) option to come up as a full-screen application and set the home page to the Citrix login. This won’t protect you from people who actively want to mess around, but for the doctors and staff, it’ll make life easier.
The shortcut you’d put in Startup would be something like
“C:\Program Files\Internet Explorer\IEXPLORE.EXE” -K http://your_citrix_login_page
If you hit F11 now, you can see what IE’s kiosk mode looks like. It’s not impossible to break out of it, but for the people that just want to get work done, it works.
I live and breathe HIPAA, but it’s not near specific enough. Citrix might be part of what we do, but again, I’m mainly looking for something so I can say to my co-workers, “See, it’s not only me who thinks it’s a good idea to hide the C: drive!” I haven’t had a chance to look too far into the references to you provided earlier, but it looks like I can find some good stuff there.
If these systems will be deployed geographically, build in some “key of the day” backdoor so you can give an otherwise unauthorized user admin rights for a limited period, using a code that will expire. This can save many expensive service calls.
You might also want to check out Microsoft SteadyState (formerly the Shared Computer Toolkit). It’s a free package for locking down shared workstations.
It’s been my general experience that properly locking down a Windows kiosk is a fairly difficult thing to do. I generally try to get out of the sandbox of whatever kiosk I’m on and I estimate I would succeed about 30% of the time. There’s a lot of different holes you need to plug and missing just one of them can allow full access.
Among some things to look out for:
IE can basically act like explorer and browse and execute programs from the hard drive
File Open dialog boxes allow you to create, edit and execute files
Accessibility settings let you emulate a keyboard and mouse
VBS scripting opens you up to a whole range of different exploits
Not IME: it just requires forethought and preparation. Tedious is probably a more apt description. Group Policies, Mandatory Profiles, etc. Here’s one of the tricks I use:
For each and every application - even CMD.EXE and CALC.EXE - create a local security group. Call it Local_App_ followed by the application name (e.g. Local_App_Cmd). Create a similarly named Domain group (e.g. Domain_App_Cmd). Add the domain group to the local group, and populate the domain group with the user IDs. Then set the permissions on the application itself such that only members of the local group and administrators have Execute permissions. This is best done with a script because otherwise it’s very long-winded.
You can’t stop the users looking at large portions of the drive; you can stop them doing any harm to what they find.
Not that particular trick, but I have others in my repertoire. For instance, you can ensure that the user does not have execute rights in the few directories to which he is allowed to write.
There are lots of issues. It just requires forethought and preparation to secure Windows.
Thanks to all who chipped in pointers. As we go along with the specific plans, I’ll add your ideas to my list of [del]demands[/del] recommendations. A lot of the nuts and bolts of it is going to be left to the desktop guys (as long as I can get their boss to buy in without too much trouble). I get to set policy, but other departments have to implement it. I can pull rank on the other dep’t managers, but I like to avoid that when possible. Hence, my desire for something to help me persuade them why this is a good idea.
A ‘political’ suggestion: paint it as less work for them in the longer run. They’ll have less fault calls from users mucking things up. They’ll have a much more standard and stable platform.
To give a trivial example: the number of account lockout calls dropped dramatically when we stopped Windows from displaying the username of the last person who logged in. 5 minutes work on our part resulted in many hours of saved time.
A subtle point here, but the number of machines has little to do with it: its the number of different packages that will create the work. Once all the security settings are detailed, it should be a case of a technician visiting each and every workstation and just running the script.
For instance, you can ensure that the user does not have execute rights in the few directories to which he is allowed to write.