Prevent malware-ridden devices from accessing IBM Worklight adapters
Christian Karasiewicz 270005XS4E Visits (3673)
This blog post is contributed by Nathan Hazout, a developer for the web and for mobile who does customer oriented R&D for IBM Worklight.
Trusteer, an IBM company, is the global leader in endpoint cybercrime prevention. One of their products is the Trusteer Mobile SDK. Trusteer Mobile SDK collects multiple mobile device risk factors and provides them to the mobile app, enabling organizations to restrict mobile app functionality based on risk levels.
In your IBM Worklight application, you may want to protect access to some specific resources or procedures based risk levels, such as detected malware or whether the device is jailbroken or rooted.
For example, you could prevent a malware-ridden device from logging into your banking app, and prevent rooted devices from using the “transfer funds” feature.
Installing the Trusteer Mobile SDK
If you are interested in those features, contact your IBM MobileFirst sales representative for licensing options. You will need to get the license files, SDK and other assets required to install Trusteer in a mobile app.
There currently isn't an automated way to install the Trusteer Mobile SDK into a Worklight app. Therefore you need to follow the Trusteer documentation to install the files manually into the native folder of your Worklight app. We hope to make this process easier in the future using Worklight components.
Using the Trusteer Mobile SDK
Before any calls to the calculated risk assessment, you need to obtain the risk assessment handle using TasD
Specific risk items can be obtained using TasD
Keep in mind that, at least in theory, the risk items' values could change in real time. Trusteer has an automatic background mode, or you can manually request a recalculation with TasD
With this data at your fingertips, you can already adapt your client-side code to react differently to different states of the device. If the device has malware detected, you can disable submit buttons or sensitive input fields.
However, as a secondary step I would recommend an additional layer of protection on the server side of your Worklight application.
Sending Trusteer scores to the server
In order for the server to always know the Trusteer risk scores for each device, I make use of Worklight's addGlobalHeader feature. I add an HTTP header called “WL_TAS” to every HTTP request to the IBM Worklight Server, which contains the generated JSON string summarizing all the Trusteer risk items. For an added layer of security, you could encrypt or sign this JSON string before adding it to the HTTP headers.
In your server code, such as adapter procedures, you can read the HTTP headers and make decisions.
Write your security test
Instead of writing code in each procedure you want to protect, you can take advantage of the very extensible IBM Worklight security tests and realms. Write your own custom realms and security tests that will read the HTTP headers and accept or reject transactions.
On the client side, prepare some challenge handlers to handle the response from your custom realm, showing an error message to rooted devices trying to make a sensitive transaction.
Trusteer integration into an IBM Worklight application is an advanced topic requiring some prior knowledge of Worklight development. Check out my post "Usi