Secure Mobile Applications, part 3 – Bringing it all together!

Hopefully it is fairly obvious from the last couple of posts how I think a mobile application can be made ‘secure enough’ to replace hardware security devices and enable many other capabilities from mobiles / tablets etc.  However I thought it may be useful to provide an overview of how the detailed components will work together to provide this capability.

Many organisations such as banks have or are already launching payment applications that enable you to make payments with your phone rather then needing your bank card, and of course there are Apple Pay and Samsung Pay etc.

So it’s clear people are becoming comfortable with mobile devices for some use cases, sometimes purely software, sometimes with hardware components involved such as Knox or TEE (Trusted Execution Environment).  This is likely helped by the rise of ‘contactless’ payments in many parts of the world.

While hardware components and secure operating system components can form part of a secure mobile application solution, they  are by no means a silver bullet.  As you still need some part of the application to run in normal, untrusted space, you still face the same problems as if there were no hardware solution in place.  What is to stop a malicious application attempting to man-in-the-middle the communications between the secure and insecure environment?  Indeed what is to stop a malicious application from just impersonating the secure component to the insecure one?

Hardware based solutions also face challenges around support and different capabilities on different devices.

This is why I have focussed on a software only proposal.

If we get to the point where we can trust and monitor a software only solution, this opens up so many possibilities – as long as you are on a supported O/S version, you can run our secure application(s) on any device, anywhere.

While we have the above mentioned payment applications, there are much wider use cases when we get to the point that we really do trust the mobile application I mentioned some of these in my original post on this topic.

As a recap, these were;

  • Become your payment instrument.  Not like Apple pay that still uses your card in the background, but actually being your card(s).
  • This can also provide a much richer user experience such as alerting the user every time there is a transaction on the ‘card’
  • Take payments in stores without the need for a physical card payment solution.
    • EMV (chip and pin) becomes EMV mobile devices and PIN / other
  • Replace your drivers license / passport / age card etc. as a valid form of ID.
  • Enable secure signing of legal / contractual documents.
  • Combine with technology like RFID and GPS etc. to revolutionise the retail experience.
  • ‘Card not present’ becomes ‘card present’ (the end of ‘Card not present’ fraud!)
  • Secure mobile banking becomes actually secure and fully featured
  • Support (or deny) any disputed transactions by providing more detailed information about the device, location and users involved
  • Become your mobile medical record – no longer do doctors or hospitals have to look up your records (or not find them), you carry a copy with you, that syncs from the central repository when it is updated

I am sure you can think of many others!

So how do the components previously detailed components all come together to proved a secure, monitored environment?

In ‘real time’ there are 5 main components;

  • The mobile app
  • Secure decision point
  • Real time risk engine
  • Authentication
  • Monitoring

 

The mobile application – this comprises all of the security components deployed to the mobile device, along with the actual application capabilities of course!  These components are the key to understanding the security status of the device.  They also providing details of behaviour, from things like location to the users activity, and authentication information.  These components have the responsibility for securing and monitoring the device and user behaviour, plus ensuring this data and telemetry is securely provided to the secure decision point and monitoring services.

The secure decision point is to provide a central (resilient of course!) control point for all application traffic to pass through.  This enables relevant data to be passed to the correct components such as the risk engine and monitoring solution(s).  In addition this provides an added layer of protection for the back end application services.  Any time the application or user behaviour is deemed unacceptable, the connection can be blocked before it even reaches the back end services.

Real time risk engine enables risk based decisions to be made based on the information from the other security components.  The secure decision point, authentication solution and ‘external’ source like threat intel and the big data platform all feed the risk engine.  This can be applied to  many activities including authentication, user behaviours, and transactions.

Authentication does what the name implies – it authenticates the user, and likely to at least some extent device.  The difference between this an ‘traditional’ authentication is that as well as authenticating at logon, and supporting multiple factors and types of authentication, is that it can authenticate constantly in real time.  Every time the application is used, information about the device, location, user behaviour etc. is passed to the authentication solution, enabling authentication decisions to be made for any application activity.  In addition to providing rich risk information for the risk engine this also enables fully authenticated transactions.

Monitoring, refers in this case to security monitoring of the system components and their data.  This provides expert analysis and alerting capabilities to augment the automated processes of the risk engine, authentication solution and security decision point.  This may be internal staff, a dedicated SoC (Security Operations Centre),  or a dedicate mobile security monitoring centre, or a combination of multiple options.

 

As you can see, all these components combine to provide an understood and secure environment on the mobile device, backed up by real time monitoring, risk based decisions and authenticated activities.

These ‘real time’ components are further backed up by external feed from intelligence sources, and by analytics performed in the big data platform.  This enables learning from the behaviour of users and devices in the environment so that the risk based rules and manual alerting can be refined based on previous and current activities and outcomes.

Depending on a combination of the security requirements for your application, and the resources available, you may not need or want to implement every component here.  Overall the detailed environment provides a software only solution that is capable of providing enough security to enable pretty much any activity.  I’d love to hear your thoughts, and any experiences of deploying and proving secure mobile applications!

 

K

Secure Mobile Applications, part 2

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..

Mobile app security concept - New Page (2).jpeg

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.

‘Authentication solution’

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.

‘Authentication Provider’

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.

K

 

Secure Mobile Applications

Subtext, can a mobile application be ‘secure enough’ to replace single purpose hardware devices?

An area I have been discussing for some time is whether we can make a mobile application secure enough that it can be trusted to replace physical devices / items.

If we can achieve this, there are many possibilities for your phone / tablet enabling it to;

  • Become your payment instrument.  Not like Apple pay that still uses your card in the background, but actually being your card(s).
    • This can also provide a much richer user experience such as alerting the user every time there is a transaction on the ‘card’
  • Take payments in stores without the need for a physical card payment solution.
    •   EMV (chip and pin) becomes EMV mobile devices and PIN / other
  • Replace your drivers license / passport / age card etc. as a valid form of ID.
  • Enable secure signing of legal / contractual documents.
  • Combine with technology like RFID and GPS etc. to revolutionise the retail experience.
  • ‘Card not present’ becomes ‘card present’
  • Secure mobile banking becomes actually secure and fully featured
  • Support (or deny) any disputed transactions by providing more detailed information about the device, location and users involved
  • Become your mobile medical record – no longer do doctors or hospitals have to look up your records (or not find them), you carry a copy with you, that syncs from the central repository when it is updated

 

The question is can we?

My take on this is yes.  But with some caveats around how, and what we need to do to ensure the safety of the data used by the application.

The great news for me is that other people are finally starting to get on board with this idea, after a mere 18 months or so it seemed like an opportune time to write in some more detail about my thoughts!

Before we start this discussion we need to adjust the mind-set from

  • thinking about a supposedly secure device that we do little to monitor

to

  • thinking in terms of real time application and behaviour monitoring to provide assurance of the application and device security, along with the user identity and behaviour.

 

For me the ‘assumed secure hardware’ stance seems terrifically old fashioned when compared to a solution where we can monitor and understand the risk profile continuously

Now we are thinking in these more current terms, just how do we go about making a mobile application as secure as a dedicated hardware device?  Indeed, when you consider the more intelligent monitoring and risk assessments we can perform in real time I would position this software solution as considerably better than the existing hardware options.

 

For me the ecosystem for a secure mobile application would comprise of the following components;

Mobile app security concept - New Page (1).jpeg

To avoid this becoming a mammoth post, I’ll cover some of the key capabilities of this system here, and provide details of each component in part 2 of this

Some of the key capabilities these components will provide include;

  • Real time monitoring
    • Data sent to and from app in real time
    • Automated blocking and alerting
    • 24*7 ‘eyes on glass’ monitoring
  • Behavioural monitoring
    • Device
    • User
    • Application
  • Application monitoring
    • Is it the correct application (e.g. checksum)
    • Is it behaving as expected
    • ‘trap’ code in the application that is only accessed of changed if there is an issue
  • Rooting / Jailbreak detection
    • Auto updates to detect new methods or ways of hiding
    • Can alert monitoring and user if detected
  • Malware detection / device interrogation
    • Device ID, software versions etc.
    • Automatically updating detection capabilities
  • User alerting
    • Alerts user if there are any issues detected
    • Alerts user of activity on their account
  • Behaviour blocking
    • Can block some or all in app activity based on the current risk profile
  • Secure communications
    • between app / mobile device and back end
    • frequently changed keys
    • key management and distribution
  • Encryption
    • White box
    • hardware
    • In field
    • In app
  • Bot vs. real user detection
    • detects bot like behaviour
    • detects remote control behaviour
    • build picture of user normal behaviour
  • Real time risk scoring of activity / transactions
    • collection of multiple data points
    • real time risk scoring, decisioning and blocking of transactions and behaviours
  • Multiple authentication methods and step up authentication
    • Policy based
    • Risk based
    • FIDO compatible
  • GEO location
    • Current location
    • Historical locations linked with behaviours
  • Fraud detection
    • Components can detect potentially fraudulent activities such as the amount entered into a field, not matching the amount sent to the back end
  • Trending and predictive analytics
    • Big data platform can provide analytics capabilities and long term trending
    • Machine learning and predictive analytics can guide security enhancements
    • May also become a saleable service for your business

This is by no means an exhaustive list, my intention is to get people thinking about the possibilities for secure mobile applications.  Hopefully this post has got you thinking about how we can secure and monitor our applications on any device, anywhere.  This really will open up a whole new world of possible capabilities for mobile devices especially in the worlds of business and consumers / businesses transacting.

Part 2 will follow in the next few days providing some more details around the building blocks in this ecosystem.

K

Application Security is more than development security

Last week I wrote about the OWASP top 10, and the main steps that I think make up an application / development security programme.  This can be found here; http://www.kevinfielder.co.uk/security/why-does-the-owasp-top-10-never-change/

Following from this I want to discuss the security of your applications is actually so much more than the secure development and assurance lifecycle along with developer training.

Doing all of the things I previously mentioned, tailored for your environment, will ensure you have as secure an application as is reasonable possible when compared to your threat landscape and risk tolerance.  However the actual application / code is only part of the security story.

So what next? Does that mean your application is secure?  Does it mean it is secure in all environments?

I am a strong believer in the principle of defence in depth.  Even if you believe your application to be completely secure under any circumstances, I would always recommend having multiple layers of defence.  Some of these layers will be independent security tolling, and some will be within the application itself e.g. security SDKs that can be incorporated invisibly into your application.

The below list will highlight a few of the areas you should consider in order to protect your applications and the data they hold about your business and it’s customers.   The list focusses on technical security measures rather than processes, which are a completely different topic.

Application Firewalling

A ‘normal’ firewall is great for providing very fast and robust IP and port based filtering.  However it has no understanding of what should be sent to the permitted IP addresses and ports.

An application firewall understands the traffic your application should receive.  The most typical application firewall is the WAF (Web Application Firewall), Database firewalls also exist.  Web application firewalls will automatically be able to protect your web applications from known attacks like SQL injection.

A further benefit is that specific rules can be created to protect against specific vulnerabilities that may be discovered by your code analysis tools or pen tests.  This can aid speed to market by protecting your application while a fix is worked on.

The key thing here is that the WAF (or DB firewall etc.) will sit between the users of the system and the application, ‘proxying’ all the connections and alerting on or filtering out malicious traffic before it even gets to the application.

Logging

While this may seem outside of the application, and indeed the SIEM / log monitoring part is, logging the right information is critical.  Unfortunately it is often overlooked.

Do all of your applications log enough information about enough events to provide real security value?  This means a lot more than just things like logon / logoff.  Any ‘security’ interesting activity such as administrative activity, user creation, permissions changes should be logged.  Also consider user activity, so that there is a clear audit trail for whom undertook which actions.

Just as importantly is this in a format that can be ingested and analysed by your security log monitoring systems?  Ideally if you have multiple applications your organisation develops you should have a standard logging format, this would be facilitated by creating / using a common logging API for all applications.

As a final thought on logging don’t forget that for the security team to be able to provide useful alerting from the logs, they need to understand what good and bad look like to your applications.

Server Application control

While perhaps not strictly ‘application’ security, a key protection that rarely seems to be implemented is strong application white listing and application controls.   I mention these as I think they make a key part of the overall protection and I had omitted to cover them in detail previously.  Servers should have a pretty static application lists so the overhead of running whitelisting controls should not be excessive once in place.  The other benefit of these solutions is they also understand how many applications should work, so they can prevent even compromised commercial applications from misbehaving.  This should be seen as a key protection for any high risk application servers in your environment, especially those hosting internet facing applications.

Mobile application and device protection / analysis

This is one of my current areas of interest.  How do we protect mobile applications that will be installed on fundamentally untrusted devices?  This can apply so normal Windows / Mac apps as well – see below.

So your application is ‘secure’.. Some questions to get you thinking about the environment a mobile application will run in;

  • How secure is it if the mobile device is compromised and there is key logging software on the device, or man in the middle software that changes the users inputs before sending them to the server etc?
  • How do your servers know if the application talking to them is your application or an exact copy of your application that has malware added?
  • How does your application stay up to date to detect the latest rooting / jailbreak methods and malware?
  • Does the behaviour within the application look like a human user, a bot, someone remote controlling it?

It is to enable us to answer these questions, and more, where mobile application security solutions come into play.  I’ll not cover these in detail as there will be an upcoming post very shortly to cover this specific point in more detail.  Suffice to say if you run mobile apps that handle any sensitive data or transactions etc. this an area you need to be all over.  This also has multiple wider benefits highlighted further down this post.

Remote host security (if you supply an application to them)

This is a similar idea to the mobile security one.  With the continuing malware epidemic across Windows, and the increasing prevalence of malware on Mac and Linux protecting your applications on remote machines should be investigated.  Again, this is especially relevant if you supply an application that processes sensitive data of any sort.

On one hand you could argue that the security of the end point is your customers responsibility, and you would be correct.  However given the challenges faced by most people, especially in the personal or SME markets is this a realistic stance to take?

Given the ease with which you can integrate a host protection SDK from one of the many vendors out there, I would certainly recommend looking into this option, especially if you charge your customers for the service.

Remote browser security

This is where we look at options for securing, or at least monitoring the remote browsers that connect to your web applications whether from mobile or more traditional desktop devices.  This is the area where we have least control, as we are not installing anything on the remote device.

However all is not lost, we can insert various security measures into the page to look for potential browser issues, ID the browser and machine, and perform cool things like in field encryption.

As with the mobile security solution I would recommend that you investigate commercial options here as they will keep themselves up to date against evolving threats and also provide a wide range of added functionality like risk scoring, automated blocking etc.

Also as with the mobile security I’ll write about this in more detail, as in my experience this is overlooked by the vast majority of organisations.

Authentication

This one shouldn’t need any introduction.  In this case what I am referring to is the confirming to an appropriate level that a users is who they attest to be.  There are however many pitfalls around authenticating users of a system.  Obviously ensuring someone is who they say they are is key to securing your applications and their users.

The added benefits of supporting better authentication than passwords are much broader than just being more secure.  You can offer a much better journey for your users, with reduced or no friction for many activities.  You can also gain a lot of useful data as many authentication solutions collect extensive data around the user and device to enable risk based authentication.

Don’t forget, how you do authentication is also incredibly visible to your users and one of the first ways they interact with you every time you use the application.  So this is a great opportunity to both provide a great impression and to highlight that you take security seriously right from the ‘front door’.

Authentication is another area I will be covering in more detail as it is critical we move away from passwords.

Further Benefits

Consider the multiple wider benefits of remote security solutions and authentication;

  • More secure customers = better security for you.
  • Offering security = differentiation and potentially something you can charge for.
  • Data Data Data – the more data you have about your customers and their behaviours, the more interesting analytics you can perform.

These benefits all apply to mobile application security solutions, remote host security, remote browser security and to some extent new authentication solutions.  I briefly explored some of these in my earlier ‘Extending the Perimeter’ article, and will expand further on these in following posts.

Conclusion

Don’t forget that this is all in addition to all the ‘standard’ security stuff you must be doing anyway such as Firewalls, IDS/IPS, anti malware / host security, standard hardened builds, vulnerability scanning and patching etc.

If you have been following my last few posts, you should have a good idea of the basics required for general and application security, plus a few more advanced thoughts from this post.  Once you have these security basics in place,  you can then start looking at the even more interesting stuff!  This includes network and application behavioural monitoring and big data analytics.

As always, do the ‘basics brilliantly’ before spending too much time on more advanced security.  Malicious individuals and groups will tend to go for the low hanging fruit.  Even if they are specifically targeting you, they will look for the easiest way in.  No amount of advanced, behavioural monitoring will protect you if you’re hosting unpatched servers on the internet with single factor authentication and simple passwords!

More next week!

K

RSA Security Summit London April 2014 – InTh3Wild – The current state of cybercrime

Talk by Nick Edwards of RSA around the current state of cyber-crime titled;

InTh3Wild – The current state of cybercrime

Trends;

1.       As the world goes mobile, cybercrime will follow

Stats and facts around mobile;

2007 – Apple introduces iPone, Google unveils Android OS

2013 – Jan – Apple hits 40 billion downloads, May – Apple hits 50 billion downloads

2012 – Android malware explodes

1 billion android devices shipped by 2018

1 million android devices currently activated / day

86% of all Android malware is repackaged versions of legitimate apps with malicious payloads

Focus of mobile malware; eCommerce, Online banking, Online trading.

–          Much of the effort is around harvesting credentials rather than trying to commit fraud via the mobile app – likely due to the limited functionality of many mobile apps

2012 – 300 million mobile bankers.

2013 – 530 million mobile bankers

71% of organisations allow their users to use their own mobile devices for company business

–          Even if you’re using a container technology could credentials be stolen?

–          What could be harvested from ‘screen scraping;?

Games are also a common app used for attacks;

–          Angry birds in space had over 150 million downloads in the first two weeks

–          Only requires a very low percentage of people to install a malicious version for the malicious user to have access to many compromised devices.

Phishing / SMSishing – SMS spoofing and phishing such as sending texts that look like they come from your bank.

SMS sniffers that sniff and send your SMS details to the criminal

Voice – recent android Trojan can record phone calls – these have 2 purposes, harvesting information, and using your voice to fool biometric systems that rely on voice.

2.       Hactivism

Political messages and defacements

DDoS and other malicious activities ‘for hire’

Trying to make hactivism legitimate – e.g. Anonymous creadet US ‘we the people’ petition to make DDoS a valid form of protest

Many different organisations such as Syrian Electronic Army (SEA), Anonymous, …

News sites as well as businesses are often targets

3.       Account takeover

Identity theft

Take over of online accounts such as twitter, facebook

Tools readily available for identity theft such as components or the Zeus plugin.

–          Can alert when users of compromised machines try to log onto banking sites and perform transactions etc. in real time

–          Keeps records of users history so they can answer questions around user behavior etc if prompted by customer services.

Security tools need to catch up with this to start dealing with these attacks that occur in real time

4.       Fraud as a Service

Cybercriminals increase effectiveness of fraud offerings

Ransomeware – scare tactics around crime and child porn etc. to extort money from users

Ransomeware – encrypts parts of or the entire computer and requires ransom to decrypt

Call centre service – fake call centres set up to call customers with compromised machines – set up locally so they sound correct and have knowledge of the local banks etc.

Analytics – crimeware now has the ability to provide ‘big data’ type analytics around its use, distribution, numbers of infected machines etc.

 

2014 – sneak peak;

–          More sophisticated mobile malware

–          Generic malware for advanced attacks

–          Bitcoin’s popularity / demand for stealing

  • Digital currencies and issues with them to become more prevalent

–          Trojans get more sophisticated

–          More breaches

Mobile is huge, criminals continue to become more organised and sophisticated with very low barriers to entry into the market.

Security must catch up!

K