This article explains how you go about using the learning mode of the individual RES Workspace Manager security models. This will enable you to more quickly turn test environments into working, locked-down production environments. Before we begin, it is important to realize that there are 5 different security layers in Workspace Manager. These are:
- Appguard – Process security, preventing unauthorized code from executing
- Read-Only Blanketing – Protects the filesystem without changing NTFS permissions
- File and Folder security – Denies permission to specific files, filetypes and folders
- Removable Disk security – Configures read/write permissions on burners, floppies and USB drives
- NetGuard – IP security, preventing apps from accessing unauthorized hosts
Each of these subsystems have their own seperate learning mode. Let’s once and for all get hammered down what learning mode is:
1) Learning mode will allow everything in the subsystem, but things not authorized will be logged
2) Learning mode can be activated globally, affecting everybody – or just per individual application
It is the objective of this document to describes the necessary steps you need to go through when implementing them. To put things in contrast, the worst possible thing you can do, is switch everything in learning mode at once and start letting the users in. This would positively drown you in logfiles which you would have a helluva time sorting out - that is, if your DBMS doesn’t buckle under the weight of the resulting database size! So let’s avoid all that and instead look at how we use these powerfull tools more elegantly, to archieve our goal of a locked down system.
During pilot (before letting regular users in)
- When starting from scratch, start with all the 5 security systems disabled. Concentrate on getting the PowerLaunch configuration as you want it (the right drives, printers, application settings, etc) At that point,switch one system on at a time. Start with Application security, then move onto read-only blanketing, etc. as you see fit.
- Set the relevant security system to learning mode globally. Log in with a regular (non-admin user). Experience shows that it serves best either a) to create a user from scratch or b) borrowing the credentials of an existing user. Why? Because admins make the absolute worst testusers in the world, usually not representative of a regular users rights. Even our “normal” accounts may have been tweaked/elevated somewhere down the line, so don’t fall for the temptation of logging in as yourself.
- When logged in as the regular user, take the system for a spin, like Jeremy Clarkson would testdrive a Lotus! Take it through the curves, make the tires squeal and have a jolly good laugh at the same time! :) Seriously, just start launching apps all over the place, doing normal stuff the user would be expected to do. Don’t worry if you don’t get out into all the corners of the apps, this is just to take the desktop and apps through it’s paces to detect the most obvious stuff. Example you’re launching application X, but at startup if you click on new-document, it may actually execute Y.exe underneath. This is what learningmode will uncover for you, so you’ll have that exposed and sorted out (authorized) long before the first real testuser is sat down and ask to try it.
- Once you’ve done the general run-through, you start examining the resulting logs. Authorize the items which makes sense. Be very wary of the fact stated earlier, that you can authorize on both global and application level. What this means is that if you authorize globally, then the authorization will hang around always, no matter what. Always strive for the posibility of authorizing something on application level if it makes sense. Why? Well, if you later remove the app from the user or the system as a whole, all the authorizations will be ripped out clean together with it. On the other hand, some authorizations do not make sense to stick underneath an app, this is usually system related stuff, like enabeling drwin.exe or similar system processes to run. In short: Know thy system - govern accordingly.
- When you’ve authorized the first batch of things which make sense, clear all the Workspace Manager logs, so you start the next serving with a fresh plate. Dont worry too much about blowing out the logs there will always be fresh data comming in, once the real users start using it. Leave the system in learning mode.
- Now grab some hapless real user by the neck and sit him down in front of the system you’ve built. Why? Because of reasons that perhaps only Stephen Hawking can explain properly, the user will usually manage to hit those buttons or go into that module of an app, which nobody ever thought of touching on the first general fly-by. Result: fresh real-world authorizations.
- Process these as you did in step 4 above. When done, you clear the logs once again and THEN you switch the security to enabled.
Repeating the 7 steps above for every security system in Workspace Manager, will ensure you accuratly draw a chalk line around the security requirements of the applications. All the stuff above is preamble to production.
Once you start letting people in to the new envirionment, chances are that something needs to be authorized along the way, i.e. stuff you didn’t catch during the pilot/PoC phase, or the user test in step 6 above. Fortunatly it is very easy for any helpdesk to catch authorizations, as you can setup Workspace Manager to send an email or generate an SNMP alert or make something else happen in the event of a user trying to execute something which hasn’t been authorized. Remember, an authorization takes effect immediatly when you refresh the effected users session, eliminating the need for the user to save work and thus being unproductive.
Once in production, the next order of business is change management, specifically what to do with a new app. There are two main approaches to this:
a) Bring in the app on a test-computer in the production environment
b) Bring in the app on a test computer in a completely isolated test environment (with a seperate Workspace Manager database)
While option b is the failsafe bet, which most CIO’s would be most comfortable with, option a is quite safe too. This is due to the fact thats you are only adding additional configuration items to the Workspace Manager environment. The apps would be installed on a seperate test computer. Think of it as having a test server in the production domain. You could consider is creating a Test-workspace, where you can dump all the test settings into. With that done it will only affect test computers. On the other hand, if you are more comfortable with option a, you ofcourse have to make sure the test environment accuratly mirrors the state of affairs in the production environment. If it doesn’t, you’re potentially building on the wrong foundation. If that prerequisite is met, things are easy: Create the stuff you need in the test env. When requrements are satisfied, create Workspace Manager building blocks, and import these into production. Regardless of which of the two approaches you decide on, there are common groundrules to follow:
First rule of business here: Do NOT switch the production environment into global learning mode once you’re up and running. It would expose the entire system potentially to anything, which we’d rather like to avoid…
- Install the app using whatever method you want to the target test machine. Again remember, Workspace Manager does not do application installation, as it is regarded as a machine task. RES Automation Manager is designed to handle these types of items. Alternatively you can use any other deployment mechanism you fancy.
- Create an application (shortcut) in the Workspace Manager console
- Enable learningmode on the application. This will ensure the rest of the environment continues to be locked down,however the new app can do what it wants, but everything it does will be logged ofcourse.
- Give the application to testusers. Limit the amount of testusers, preferably to 2-4 users if possible. Chose trusted, real users, who are likely to use the app as they’re supposed to, but understand the concept of that they are helping toverify that an app works as it’s supposed to.
- Ask them to use this app and take it for a spin.
- Observe the security logs. Authorize stuff on the application level which needs to be authorized.
- Once satisfied that you’ve captured, analyzed and authorized enough security item for the app, set the application back into blocking mode. Continue testing if you deem necessary, or proceed to next step
- Change the access control on the app and give it to the folks that need it. The app is now officially in production. If blockings happen further down the road it’s either a) something helpdesk needs to remedy, as described in the In production section above, or it may just be the user trying to do something they weren’t suppossed to (like opening mediaplayer on a citrix server, etc)
A final note regarding authorizations on applications: Please keep in mind that when you view the security log on an application, the log will be filtered to show only events generated by the main executable. Example: If you’ve create MS Word as a Workspace Manager application, the main executable would be <installpath>winword.exe. Let’s say that during learning mode it is discovered that as a part of launching a macro, winword.exe calls an example wordxyz.exe, which then again needs to call rundll32.exe. Now we need to authorize these two links down the execution chain on the app, as it has to do with Word as a whole. However the problem would be that the log won’t be showing wordxyz.exe, since it will be filtered on the first link in the chain, being winword.exe. The attempt of wordxyz.exe to execute rundll32.exe will however be logged in the global Apguard security log. The current only way of dealing with this is to manually create a rule on the app, where you specify that wordxyz.exe is authorized to execute rundll32.exe
This pretty much covers the initial and day-to-day operations of the Workspace Manager security model. If you have questions, please comment.