My last post covered some of the benefits of getting to a point where a mobile application can be considered ‘secure enough’ to replace dedicated hardware solutions, including the required mind set move from ‘assumed secure hardware’ to ‘constantly monitored and assessed software’.
As part of the post I included the high level security architecture components / building blocks that be part of the secure mobile application ecosystem. This post will provide some detail about what each component is and cover their features / capabilities.
For ease of reference I’ll repeat the diagram here. Observant readers will notice one extra box added since my previous post..
I’ll start by covering the security components that will be included in the application on the mobile device;
‘Mobile Security Solution’
This forms the core of the security solution on the device. Most likely implementation would be an SDK that is integrated with the mobile application and ideally has a dedicated security ‘decision point’ in the architecture before the mobile app connects to the back end services.
This component will provide the core security component on the mobile device providing multiple capabilities including;
- Jailbreak / root detection
- Malware detection
- Key management and secure communications
- Bot / remote control behaviour detection
- User and device behaviour analytics
- In field encryption
- Potentially fraudulent transactions (e.g. amount sent differs from the amount entered in the field)
- Application and device tamper detection
- Application checksumming
- Code obfuscation and tamper detection
These outputs are all used to create a risk profile of the application environment covering device, application and user behaviour.
This component will also have the capability to send the telemetry to a dedicated third party SOC (Security Operations Centre) for direct 24*7 monitoring and alerting.
The core authentication component of the solution that will enable the use of various authentication methods to log into the app and also ‘step up’ authentication when performing certain in application activities.
It would be expected that the authentication solution would be FIDO compliant (https://fidoalliance.org/) and provide a variety of authentication solutions from photos to positive device use such as shaking it to push notifications through SMS to actual passwords. Risk based authentication should also be supported.
What do we mean by risk based authentication? This is where were utilise a variety of behaviour and device attributes to confirm or support the identification of the user. This can be used to support other authentication, e.g. fingerprint, plus uninfected device, plus location, plus time and behaviour is much stronger than the finger print alone.
Risk based authentication can also help provide an improved user journey. For example you may decide that when logging into an application or dashboard, if the user only wants to view certain information or perform low risk tasks risk and behaviour based authentication may be all that is required. e.g. bob in his business logging in from the same, uninfected device, at the same location at the same time, to view that days sales.. might need no further authentication.
This is where ‘step-up’ authentication then comes in. Should bob then want to perform a more ‘administrative’ task such as changing the account money is paid to, increased authentication would automatically be requested such as biometrics, one time SMS’d pin etc.
It is likely that the capabilities of the authentication solution will have some limited overlap with the security solution, however this will likely be complementary and provide an improved level of protection. This aligns with the ‘defence in depth’ security stance.
‘White box crypto / Hardware Security Module’
This box provides the capability to use encryption within the mobile device in a more trusted manner. This is especially important if there are any concerns that there may be malware trying to access the data on the device.
White box cryptography is a software solution that purportedly provides secure cryptography in even should the keys etc. be compromised e.g. it provides secure crypto in insecure environments.
Hardware security module in this instance refers any hardware security solution available on the device such as ‘secure element’ or TEE (trusted execution environment).
‘Secure Data Entry Solution’
Where there is a need for trusted data entry, e.g. a pin, there may be a requirement for a dedicated solution to this that provides extra security and obfuscation for any inputs to the application.
As with the crypto solution this may or may not be required depending on the security requirements, risk profile and how much the security software and monitoring is trusted.
‘Dedicated Mobile Security SOC’
As mentioned earlier, the mobile security component(s) can report directly to a dedicated SOC that will provide an expert layer of monitoring and understanding of the current risk posture of the device and app.
This would provide an added layer of security and expertise, which may be especially relevant in high risk and / or high transaction environments.
‘Reverse proxy / application delivery device’
The premise of this component in the ‘data centre’ (DC, or cloud) is that it provides a dedicated security device that sits in the transaction path. This provides a dedicated secure ‘choke point’ to make decisions and prevent malicious connections before they reach any of your back end servers / services.
This solution would effectively be a conduit / connector between multiple security components on the mobile device and within the DC, including the real time risk engine and the log monitoring and alerting solution.
The benefit of having this component in place vs. some of the solutions that provide similar capabilities but rely on decisioning within the application back end is that it provides a hardened device to protect the solution. This also minimises required changes to the back end of the application in order to provide this security capability.
This is the back end of the ‘Authentication Solution’ that will provide the policy based authentication capabilities and ensure the appropriate level of authentication is required for any given activity. Based on the implemented policies of course.
Ideally this should support multiple policies to enable different applications, user groups and behaviours to have different authentication requirements. This should also be able to support different authentication methods for the same behaviour depending on a combination of device capabilities and risk.
Another key theme for the authentication solution is that you ensure you work with a vendor who is committed to remaining current as new authentication methods become available. Once your application is integrated with the authentication solution you can then remain current and support what ever authentication methods you deem appropriate with no further application changes.
‘Real Time Risk Engine – Risk Based Transactions’
This block indicates the capability to provide real time risk scoring of activities or transactions as they happen. As this has to be in real time and potentially support 100s or 1000s of activities per second it is likely that the rules will need to be relatively simple and easy for a machine to check against in real time.
These will however be refined and improved over time via the longer term analysis performed in the big data platform.
The benefit of having real time risk scoring, and blocking of transactions is that you will prevent a lot of potentially bad activity such as fraud before it even gets to your core systems.
The risk engine will be able to combine the current session profile information from the various tools in the environment, along with some understanding of expected user behaviour.
An example of the kind of contextual risk scoring the solution may provide would be;
Alice logs into her device using strong authentication, there are no indicators of compromise on the device or application and she is in her normal place of business. Some unusually large transactions are sent from Alice’s device, but there are still no indicators of any issues These can likely be permitted with very low risk.
Alice logs into her device using her password, there is an indicator of some potential malware, but nothing that should impact the application. Alice and the device are not one of their usual locations. Some unusually large transactions are sent through. While not definitely fraudulent these would definitely carry a higher risk score and may want to be blocked or investigated immediately.
The real time risk engine would receive contextual information from the various components in the mobile application security ecosystem, general threat intel about fraudulent behaviour etc. from the external threat feeds, and updated algorithms and intelligence from the big data platform.
There may also be a link to a dedicated fraud system if this is a financial organisation.
‘Big Data Predictive Analytics’
If your organisation has one, this would be the big data analytics solution that is in place. Data from all the security tools and threat feeds, not just those for the mobile app, should end up here.
This will then use analytics, machine learning, data scientists expertise etc. to learn the environment and understand how well the real time risk engine is working. This data would then be used to improve and refine the rules to maximise performance and detection while minimising false positives.
Outside of providing analytics and improvements to the mobile platform, there is immense business and competitive advantage that can be gained from analysing and learning from your security tooling if you can get the whole picture into one place. This is especially true if you have enough data to start making accurate predictions for you and / or your customers!
‘External Threat Intel Services’
These are exactly what they say on the tin, your organisations sources of external threat data. While the value of these can be questioned, if you have them, especially if you have found a reliable source of accurate, timely and actionable contextual data then they should certainly feed into you risk engine and data analytics.
‘MSS Monitoring Service’
This is your organisations general security monitoring and alerting service. This will likely comprise a SIEM (Security Information and Event Monitoring) solution or Continuous Monitoring solution of some sort and a team of dedicated security analysts. I have shown this as an external service as this is usually the best way to deliver this to small and medium organisations, along with many larger organisations that do not have security as a core competency. This could of course be provided by an in house solution and team if that is in place in your organisation.
This service will provide monitoring and alerting on any potential security issues and either investigate and initiate incident response and remediation directly or work with your security operations team to do so.
This post has turned into quite the essay, I’ll stop here as we have briefly covered the various security components within the mobile application ecosystem. How this all hangs together and provides a cohesive secure environment will be the subject of my next post.