Justifying Security Spend

Given that  this often relates to proving a negative, justifying security spend can be extremely challenging.  Before we continue, I’ll freely admit I don’t have all the answers here, but wanted to share some of the things I’ve been thinking about and discussing recently about just how hard this is, and possible ways to help.

We weren’t hacked therefore we spent enough..  Did we spend too much?  Could we spend less and still ‘not be hacked’?

We suffered a data leak, did we not spend enough?  Did we spend on the wrong things?

 

One example I am using to demonstrate how hard it could be to justify seemingly obvious security spend is around DDoS.

Take the following scenario;

Your organisation has suffered some DDoS incidents, these were volumetric attacks and the board urgently wants protection from these types of attacks in place.  You duly implement a premium cloud service, and provide them with an overview of the service and how it protects against volumetric attacks.  Over the next few months the service proves it’s worth and protects the business from any further attacks.

The next year, gaining approval for spend on this service is easy, everyone knows what it does and that it is needed.

Over time volumetric attacks against your business cease to occur, and a couple of years later the board are challenging the need for a large spend on protection from these attacks.

However the question clearly is; did the attacks cease because you are no longer a target of this type of attack, or because it is common knowledge you have very effective protection so there is no point in launching these attacks against you?

 

From this example you can see that justifying spend on something as seemingly obvious as DDoS protection could be challenging as how do you go about proving why the malicious actors have not done something?

 

Taking another example I read in the most recent issue of the ISACA magazine;

Before the Best Buy breach, what were the chances that they would be a target and suffer a breach?  After the Best Buy breach, what are the odds they will be breached again?

 

We have models for things we think we can predict from sporting events to the weather that have varying degrees of accuracy.  However the various malicious actors that could be targeting your organisation do not act in ways we can easily predict and quantify.

So given this how do we clearly state to the wider business the actual likelihood of an event, and the impact?

I’ll leave the impact discussion for now, but while it many seem more obvious, consider the wide range of impacts and how hard they can be to accurately quantify.  It is relatively easy to state how much you loose for a given amount of downtime, but how long does reputational damage last? How many sales are lost over the next year with downtime or a breach being factors in the customers decision? etc.

 

Some key things to help this situation include;

  • Moving the security discussion from IT to the ‘business’, all security risks are actually business risks, or translate directly to business risks.
  • Running scenario based exercises with the board to understand their risk appetite and educate them around what can happen and the impacts it would cause.
  • Gathering industry information on the prevalence of attacks and breaches against what are considered ‘peer’ organisations to understand the threat landscape you are operating in.

What are your thoughts?

How are you ensuring the  executive board and the wider business understand the need for the security spend and how you are managing risk?

 

Thanks!

 

K

CYBERRisk Europe conference

I’ve spent a little time at the CYBERRisk Europe conference this week, both as an attendee and as part of a panel discussion.

One of the most interesting things about this conference is it has been formed as part of the OpRisk Europe conference.  This is a conference focussing on Operational Risk.  I think it is great that people are trying to bring these things together as while “Cyber”, however you choose to define it, is a category of risks, these all come back to business / operational risk and impact.

Cyber / information security / <insert latest buzz word name here> risk must be considered as a part of the overall business risk, while the people assessing the risk may be from different teams this still needs to feed into one central, organisation wide process.  Doing this ensure all risks are considered together, clear business owners of any risk can be identified, and those owners along with the wider board have a clear view of their cumulative risk.

I don’t think that many companies are necessarily there yet, but brining your risk processes and recording / reporting under single organisation wide umbrella would definitely be beneficial.

Other highlights from the conference included some great discussions around;

  • The importance of working with your business and the board to understand and define the risk appetite
    • A great way to help with this is to use various scenarios around what is and isn’t acceptable
  • Ensuring Security is seen as a business, not IT issue, despite Cyber being very IT centric
  • Using Cyber exercise and playbooks
  • The fact that Cyber / Security is a ‘wicked problem’ – look this up!
  • How related Cyber and wider risk is, but that Cyber is likely a faster moving space than organisational / operational risk are used to
  • Where the CISO / security organisation should sit in the organisation.  There was not consensus, other than not within IT, especially for regulated industries.  Thoughts included within the CRO or COO office, or even the CEO office
  • The need to think outside the box to find better ways to solve difficult security problems was frequently discussed – think of the Gordian knot.  Are we solving security problems in the right way?
  • Ensuring that the relevant people in the business understand and care about cyber risk is key to getting buy in for the correct mitigation / remediation / acceptance decisions
  • Being realistic about aspiration vs. realism vs. appetite, for cyber risk – but likely applies to many areas!
  • The fact that contain and respond need to be seen as at least as important as prevent and detect
  • The importance of people, culture and awareness as well as tools and processes must not be overlooked
  • How challenging it can be to justify cyber / security spend, even for seemingly obvious things as we are often ‘proving the negative’ – more on this in a following post.

 

This was a relatively small conference, but well focussed, with some good content and discussion, I’d definitely recommend it.

If you have any questions about the above topics, feel free to ask and I will happily expand on them.

Cheers

K

We must not forget the basics!

Short and sweet post today!

While I regularly talk about new security things such as predictive analytics, machine learning and making security a profit centre, we must never forget the basics!

I was recently asked how I would spend a limited security budget, by a vendor after I suggested HSMs were possibly not the best investment vs. other capabilities if your physical environment is secure, but that is definitely another topic!

My response was that regardless of the latest new security trend or capability, getting the basics right has to come first.  I don’t recall where I first heard it, and it’s certainly not original but the mantra;

“Be brilliant at the basics”

This definitely applies to security as much as many other areas.

I’m not going to list what I consider to be the basics here, I have talked about them before, and there are plenty of great sites covering this topic already.  Two places I would recommend looking are;

SANS / CIS critical security controls for a general list of key basic controls you really must have in place;

https://www.sans.org/critical-security-controls

OWASP top 10 for a more application specific list of the basics you need to be getting right in relation to applications, with a focus on web applications, but many of the points can be applied to pretty much any development;

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Happy reading, and remember while the latest tool or solution is likely more interesting, without a solid base of the security basics no matter what you do you will likely be breached via a very simple method!  Fix the ‘low hanging fruit’ first, then do more advanced security.

K

Turning Security into a Profit Centre

Security is still seen very much as a cost centre or necessary evil that is a ‘cost of doing business’.  This, along with a historical challenge around gaining traction at board level has driven the slow move of security to being a key part of most businesses.

This is true even in the industries where security is now seen as critical, and where the board has time and an appreciation for it.  In these industries such as financial services, gambling, big pharma and even gaming, getting funding, resourcing and executive support for security programs is less of a challenge.  However even with this support, the view is still one of security being a cost of doing business.

In order to progress further and make security genuinely a key part of the business, we need to move the conversation on again.

Over the last few years CISOs and security teams have worked diligently to understand their business and speak in the language of their business peers.  This has been a key factor in gaining board support for security.

The next step is to move this further, and work out how security can become a key pat of the business offering for your organisation.

This should likely begin in terms of how you differentiate yourself in the market.  Start thinking along the lines of;

  • How is your companies security different or better than others in the market?
  • How do you ensure your customers data is kept secure?
  • What reassurance can you offer your customers?
  • If your business involves medium to longer term partnerships can you become your customers ‘trusted partner’?
  • Do you have an impeccable record e.g. never been breached, never lost customer data etc.?

The aim here is to think about ways you can make your strong security a part of how your organisation sells itself.  Security needs to become a part of ‘who the organisation is’.  By doing this you’ll move security to the ‘next level’ in the business where is isn’t just a boardroom topic because it has to be, but it is a boardroom topic as a key part of what you do.

By making security a key differentiator for your business, you’ll also make security much more part of the conversation across the business as it becomes part of how your organisation sells itself.

 

Now for the really big bet! Can we move security even further, to not just be a differentiator, but to become something you actually sell?

Whether this is possible or not will depend on your industry, company size, customer base etc.  However if it is possible, think of how powerful this could be!

Imagine not only the benefit to the standing of the security team if you are able to actually sell services and solutions to your customers, but also the benefit to the actual security / risk posture of your organisation!

Have a think;

  • Do you hold large volumes of data on your customers, or their customers?  Could this be used to provide valuable security analytics such as fraud or unusual behaviours?  Could it even be used to provide predictive analytics?
  • Do you run enterprise scale services that you could provide at a relatively low incremental cost to your customers such as encryption, tokenisation, authentication,  …?
  • Could you support your customers in achieving compliance with whatever regulatory environment you work in?
  • Is it possible to securely host your customers services in your own DCs?  This has the added benefit on ensuring communications from the customers systems to yours are secure.
  • Can you provide them other capabilities such as monitoring, vulnerability scanning / management, secure coding guidance …
  • Insert your ideas here!

Seriously, if you work in security, and especially if you have a leadership role think about this.  It’s time for a step change to really make security front and centre of your organisation.  Lets stop being one of the ‘costs of doing business’ and become a core part of what our organisation does!

K

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