One advantage (and limitation) of CIT's Virtual Desktop service is that they limit what applications you can run to the ones they host. (You can package apps for them to host.)
See also
- Consider: Migrate select staff to CIT's Desktop Everywhere
- Evaluate CIT's Desktop Everywhere on Dell Wyse all-in-one system
AWL: Application White Listing
VDI service | Today's staff desktops | Desktops with white-listing |
---|---|---|
100% whitelisting. If CIT hasn't allowed it, it won't run.
| If Admin access required for an install, most end-users can't install new software. However, if software can just be used without installation, user can run it. For example, Putty.exe will work. | Can run in audit-only mode to first learn of potential impact. See below idea for more. |
Idea: Run whitelisting on existing systems which we believe could be moved to VDI
This would be a way to reality-check wisdom of such a move.
- No other changes would be necessary. Users keep their systems as they are, with their current applications and set-ups, and using their current Windows OS version.
Also, this can work for Mac OS, if tools are found for that operating system. (VDI is Windows-only.)
Phases
Phases can help us think about advantages of this approach:
Phase 1: Learn tools available and what apps are being used today
- Can run in audit-only mode to first learn of potential impact.
Phase 2: Have users approve or reject any non-listed apps
- Chemistry IT then reviews all approved ones for consideration of adding to the white list.
Phase 3: Perhaps not do, but possible: Only allow whitelisted applications to work (same as CIT's VDI service does)
- Users have to wait until Chemistry IT approves any new application requested.
Oliver's idea tool
For IT Admins:
Great Admin interface letting one see unauthorized apps, by user/ machine.
Run through a "clean", newly imaged system with representative applications to build whitelist.
Easy to add new application to whitelist. Easy to approve updates to already whitelisted apps.
Have approved application apply to applilcation's files, etc.
Approval based not just on name. Maybe a hash, publisher, etc.
User experience
For phase 1
Record all non-whitelisted apps.
For phase 2
User launches app:
- If app whitelisted, launches per normal.
- If app not whitelisted, user advised app is not whitelisted and given options:
- Launch the app. In which case that gets recorded and sent to Admin console for IT follow-up. Including considering adding it to the central whitelist.
- Cancel the app launch because not app user wanted.
- Optional option Cancel the app, but permit meta-data of app sent to Admin console for IT follow-up. Including conversation with user on what their needs are. Consult: Options, alternatives, licensing, etc.)
For phase 3 (if done at all)
User launches app:
- If app whitelisted, launches per normal.
- If app not whitelisted, user advised app is not whitelisted and launch stopped.
Technical implementation ideas
In many ways, CIT's VDI service allows less control than having Faronics's DeepFreeze on a computer. And DeepFreeze can prevent necessary updates. But what about Faronics’s Anti-Executable Enterprise, if Microsoft’s solutions (AppLocker, Device Guard) don’t meet our needs?
Resources
Faronics’s Anti-Executable Enterprise:
Lock down Windows 10 to specific apps:
Microsoft AppLocker overview:
Microsoft Device Guard overview:
Top 10 Common Misconceptions About Application Whitelisting (FEBRUARY 19, 2014)