You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

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

AWL: Application White Listing

VDI serviceToday's staff desktopsDesktops with white-listing

100% whitelisting. If CIT hasn't allowed it, it won't run.

  • Even run-alone apps won't work unless permitted (such as putty.exe).
  • CIT makes tools available so IT professionals can use to package (and maintain) any application, which CIT then hosts.

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)

 

 

  • No labels