Extending client-side analyzis (example : Test Registry Key)

  • Article

 

IAG is able to inspect your workstation and then later, per application, verify if you are compatible with the security policy.

For example, you want to make sure that only “corporate” machine can access ApplicationA, but everybody (of course after authentication) can access applicationB… etc.

You can go even deeper, and specify that for applicationA, download is authorized only if “bitlocker” is installed on the machine.

Workstation analysis and security policy is one of the most important feature when talking about “application layer” (versus network layer) security.

But what if you want to test something that IAG cannot check by default ? What if you want to test a security software that is not part of the supported applications ? No hurry, it will take a mn with IAG.

The procedure below shows you the A to Z procedure to extend IAG. The first “extra check” you add requires a few customization, but then the other just take a few seconds, so don’t be afraid by the things to do the first time.

BASICS

Workstation analysis is initiated by an ActiveX/Java executed on the client machine. In fact, this client downloads a “Visual Basic Script” file which contains all the functions that will generate this > 200 checks.

So if you want to extend client-side analysis, you just need to create your own VBS, and add the appropriate code that will gather the information you want to secure your application.

In this example below, we want to test if a registry key is present on a machine. This is a frequent request from customer, for example to determine if it is a corporate machine.

THE SCRIPT (Sample)

On the IAG machine, go in "/InternalSite/scripts/CustomUpdate" directory. Put you script here (MyScriptName.vbs for example). Here is a demo code :

 

On Error Resume Next

‘You gather the information you want, here a registry key
bExist=Whale.Registry.RegKeyExist(rkHKEY_LOCAL_MACHINE,"SOFTWARE\TestKey")
if Err=0 And bExist then

      'Results command wil create a session variable
Results("IsACorporateMachine")=True

   ‘This command will add a line in the client-side trace, if tracing is set to true.

       Whale.DebugEcho "Key is there, this is a corp machine"
else
Results("IsACorporateMachine")=False
Whale.DebugEcho "Key is NOT there, this is NOT a corp machine"
end if

 

As you can see, the VBS is pretty standard except:

· IAG client-side component exposes via COM some functions. You have an example here with “whale.registry.regKeyExist”.

· “Whale.debugEcho” is used to generate tracing in the “client-side” log, very important for debug/performance purposes.

· “results” function is in fact the function that will send the result of your analysis back to IAG. This function will add a “variable” in the analysis result, and will also return the “value” of this variable.

At this level, the script is here but IAG does not know that it has to add it in the global analysis process. We need to change a configuration file to do so.

1) Go in InternalSite/inc/CustomUpdate

2) Create a file called <trunk_name><0 for HTTP, 1 for HTTPS>Detect.inc

3) In this detect.inc, add this :

<%
g_scriptList.add "/InternalSite/scripts/CustomUpdate/MyScriptName.vbs", "this string does not really matter"
%>

This piece of code just adds your VBS in the global analysis process.

You need to activate the configuration via IAG console, and do not forget to check the “checkbox”.

At this level, workstation analysis will take place.

Firewall rule

This new “customupdate/myscriptname.vbs” has to be added in the firewall, otherwise IAG will block it. Go in ruleset and add a line for this file.

Display custom Variables in IAG GUI, policy section

client-side is ok now, workstation will take place.

We have still one thing to change. We want this variable to appear in the IAG console, so you can add it in your security policies.

Create a file names von/conf/CustomUpdate/PolicyTemplate.xml. Put this content in it. If you have more than 1 variable just duplicate the POLICY XML section. The "NAME" tag will be the name displayed in the GUI. The ID is the name you are using in your custom script.
<Policies>
<Policy>
<Name>This is the name that shows up in the editor</Name>
<ID>This_is_the_variable_name_you_used_in_the_script</ID>
<Type>0</Type>
<Value>DefaultValueGoesHere</Value>
<Description></Description>
<Section>Variables\Where\ItShould\Show\Up\In\The\Editor</Section>
</Policy>
</Policies>

 

Once you have done this, go in IAG console and activate the configuration with the checkbox. Now, you MUST EXIT IAG console, and re-execute it : IAG will refresh the list of variables only when it starts.

What happen if I want to test other things ?

As I said in the beginning, the first time you extend IAG, there are several things to do.

For the next ones, it is quicker :

1) Just change the VBS (all your tests MUST be in 1 single VBS), and use “RESULTS” function to add more variable in the analysis

2) Update policytemplate.XML to display those variables in the GUI

You want to go further ?

Best thing to do if you want to go deeper is to check the script that is supplied by default in IAG (and updated every time there is an UPDATE, or a SERVICE PACK).

Edit this file : C:\Whale-Com\e-Gap\von\InternalSite\WhaleDetection.vbs

Based on this example you will be able to detect many aspects of the workstation and then secure access to applications and data.

onecare

You are all set !