...
AWL: Application White Listing
| Topic | VDI service | Today's staff desktops | Desktops with white-listing |
|---|---|---|---|
| Application white listing. | 100% whitelistingwhite listing. 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. |
| Ensuring work files are backed up. | Integrated into the service. VDI has robust end-user file storage. | Varies. Users might have work data only on their desktop. And that data might not be backed up. Users could be disciplined about only having work data on file shares, cloud storage, and the like. Users who must have unique locally stored data could work to ensure those files get automatically backed up. IT could start using Folder Redirect for Windows systems. | Same as with "Today's staff desktops". |
| Ensuring work files are accessible by others if person is out. | Same as with "Today's staff desktops". | See answer in "Ensuring work files are backed up." for this column. If files should be able to their supervisor and others, user must be deliberate about making them accessible when using a files share, cloud storage, and the like. | Same as with "Today's staff desktops". |
| Staff desktop environment is accessible anywhere, even if their office computer hardware is no longer working or accessible (fire, flood, theft, snow emergency, etc.) | No problem. No matter what happens to a user's workspace, their desktop is hosted by CIT and available via any browser or thin-client capable networked computer anywhere, anytime. | Problem! But how likely is this scenario worth protecting against? Answer might depend if files are on a file share, sync'd to a cloud service, or otherwise not isolated to the desktop computer. If files backed up, less convenient. | Same as with "Today's staff desktops". |
Idea: Run whitelisting on existing systems which we believe could be moved to VDI
...
Why do this at all?
- To reality-check some of the issues involved in moving to VDI, and 100% white listing environment.
- Represents the potential to capture some of its benefits of moving to VDI, but without having to move at all.
- No other changes for users would be necessary. Users keep their systems as they are, with their current applications and set-ups, and using their current Windows OS version.
...
- It's something that will also work for Mac OS,
...
- unlike VDI which is Windows only. Assumes appropriate tools can be found for Mac.
- Even if just monitoring, and not actually blocking, we'd have clarity and visibility on all the applications being run on monitored computers, whether applications were installed by IT or not.
- Are there apps we should be installing because they are needed by we don't know about them?
Considerations for not making this investment
This will not reduce support calls for the computers we would be able to add white listing to because such calls are basically down to zero now.
- One reason this is so is that all those systemsl require Admin access to add new programs, and end-users don't generally have this authority.
- However, laptop users tend to have an Admin account. Adding whitelisting (even if just a warning or monitoring) could afford some protection.
This will not provide some of the other advantages of moving to VDI.
- See topics in the above table, other than, "Application white listing."
Phases
Phases can help us think about advantages of this approach:
...