Security Analytics

Overview of IBM MobileFirst™ Platform Foundation security

Applications and adapter procedures can be protected by a security test. The test includes one or more realms. Each Realm represents a specific security check. Some realms are already provided. For example, wl_antiXSRFRealm is used to avoid cross-site request forgery attacks. Other realms are defined by the developer based on their security needs.

The realms contain two key pieces of functionality: an Authenticator and a Login Module. The Authenticator gets some information from the user or device, such as a user name and password. The Login Module gets information from the Authenticator and validates it. An example of validation is checking the user name and password against a user registry.

For more information about security, see MobileFirst security overview.

Example use case

1. A developer creates an adapter procedure. The procedure returns account information for a specific user.
2. Only valid users can access account information, so the developer protects the procedure with a security test. That adapter procedure is now a protected resource.
3. You can determine if a user is valid by contacting a user registry. The developer creates a realm and makes the authenticator the FormBasedAuthenticator. That authenticator will send a login form to the client and expect a response with the user name and password.
4. The Login Module is a Java™ class implemented by the developer. It contains code to contact a user registry on the backend using the credentials gathered by the FormBasedAuthenticator. There are two possible outcomes now:
   1. If the user is valid, the security test passes and access to the protected resource (account information for the user) is granted.
   2. If the security test fails, then the user is unable to access the protected resource. The cause of the failure might be incorrect credentials, failure to access the user registry due to a network error, exception on the server, or other causes.
5. If the user is valid, the security test passes and access to the protected resource (i.e. account information for the user) is granted. b) If the security test fails then the user is unable to access the protected resource. The cause of the failure might be one of the following: wrong credentials, failure to access the user registry due to a network error, exception on the server, among others.

Potential use cases

The platform can be used to develop a banking application. The application allows users to log in using their bank's credentials. Successfully authenticated users can access their account information and perform various actions (such as transferring money between accounts). This authentication flow is similar to the flow described in the previous section.

Network issues

If an application gets popular, more people are trying to access a protected resource (such as their account information). Using the Security tab of the Operational Analytics console, you notice a high failure rate on one of the realms. That realm is part of the security test used to allow users to log in and view their account information. The most common error under Authenticator Failures is an internal server error. One reason for this error is that the backend infrastructure (the number of servers) needs improvement to meet the increase in demand.

Security threats

You notice that there is a high failure rate on one of the protected resources (such as account information). Looking at the Authenticator Failures, you notice the most common error is invalid credentials. That error gets returned when the client supplies an invalid user name or password. This might mean a hacker is attempting to access a protected resource by trying different credentials within short time intervals. Based on this information, you conclude that you should not allow users to try different credentials indefinitely. With the data provided by the analytics console, you decide to let users attempt 5 wrong credentials before asking users to wait a specific amount of time before allowing them to try again. The goal is to limit the effectiveness of a brute force attack.

Application usability issues

In addition to using their user name and password to access the application and view their account balances, users also need to supply their bank's pin number to transfer money between accounts. You notice a high failure rate in the realm that asks for the pin number. Looking at the Authenticator Failures, you notice the most common error is client interaction required. This means the server is expecting credentials (the pin number) but is not receiving them. This can be caused by a high percentage of users inability to understand the user interface. The users are not noticing that they need to send their pin number. Based on these findings, the page should be redesigned to solve that issue.

Development defects

You are viewing security information from the last 24 hours and notice the failure rate for one of the realms is 100%, meaning that it always fails. This might result from a recent change introducing a regression that broke one of the realms. Another possibility, based on the realms provided by the platform, is that wl_directUpdateRealm is failing. This happens because of an issue with direct update. A third possibility is evident when an entry with [Unknown Realm] is displayed in the list of realms. This happens when there is a failure before one of the realms is reached. Having this information is especially useful when running an application in production.