Convenience and security.. when you loose a factor..

I noticed recently that the application I use for securely accessing email and other office related things had been updated to accept my fingerprint instead of a PIN.

While this is indeed convenient and it saves me the 2 seconds of inputing my 6 digit PIN, however it does mean that an authentication ‘factor’ has effectively been lost.  Previously I used my fingerprint to unlock my phone, then a unique PIN to access the email application.

Stepping back briefly, for those not familiar with authentication, when we refer to factors we are basically talking about different ways of authenticating yourself.  These are usually split into;

  • Something you KNOW – e.g. a password / passphrase / PIN
  • Something you ARE – e.g. biometric things like finger prints, voice recognition etc.
  • Something you HAVE – e.g. your bank card / credit card, a ‘token’ that generates pseudo random numbers or a device like a phone (but do you really trust your phone to be secure as much as a credit card?..)

Things like risk based authentication based on combinations of your and your devices behaviour may also be considered, although standards like the upcoming PSD2 (Payment Services Directive 2) don’t yet formally consider these a factor.  I personally believe that they should be, but this is really a decision for your organisation around how much they trust different forms of authentication.

As a side note, authentication is, and should be considered more of a ‘shades of grey’ rather than ‘black and white’ exercise.  What I mean by this is – for any given action do we trust enough that dave is dave in order for him to proceed?  If not then we should request further authentication such as another factor or further information in order to allow the next action.

So back to the factors, and why they are important.  Many sites may have a variety of ways of authenticating you like passwords, PINs, the challenge / response questions such as what was your first school, identify the image you chose previously… – the issue here as you have no doubt worked out is that these are all ‘something you know’.  So no matter how many questions a site asks you, it is still single factor authentication.

The reason why we prefer multi-factor authentication vs. single factor is it is much less likely that a malicious actor will have access to multiple factors.  For example they may find your password, but not have your fingerprint, or they may have a copy of your fingerprint from your device, but not know your PIN etc.

This is why I question the reliance by many applications, including financial ones on just asking for your finger / thumb print again.  While I recognise that the device (phone in this case) may be considered a factor in terms of being something you have, I question how much we can trust such an untrusted device as an authentication factor.  Is this a tiny extra bit of convenience at the expense of security?

Were other capabilities such as device and behaviour analysis are not in play, then yes I believe it is a loss of security.

The caveat here brings us back to my earlier point, regardless of the other factors in play, we should and must make use of the rich data we have about user and device behaviour. By these I mean the status of the device / browser accessing our systems.  Can we detect malware?  Where have we seen the device before? When? what else do we know about it? – O/S versions, software etc.  Similarly for the individual, what are their usual behaviours on our systems?  How much do they purchase? What devices do they usually access them from? etc.

What is the point of this discussion?

  • Consider convenience vs. security
  • Play close attention to the components and factors in your authentication flow; If you consider a device ‘something the user HAS’ do you really trust it enough?
  • Make use of risk based and step up authentication; When the users is performing low risk activities, allow a seamless path.  When they want to perform something higher risk, step up the authentication and ask for more information such as another factor.
  • Possibly most importantly, make use of the risk data you can gather about the user and their device(s) in order to make the most informed decisions that balance risk vs. convenience and ‘the happy flow’ through your systems

 

It would be great to hear your thoughts on this topic!

K

 

 

Low friction, secure online payments

Online payments whether made from a traditional PC or any mobile device must be secure, strongly resistant to fraud, and convenient.

Currently online payments suffer from a couple of key issues relating to ease of use and security;

·         Extra security features such as 3DS (3D Secure) provide a frustrating consumer experience.  This leads to consumers abandoning shopping carts and merchants disabling the feature where they are provided the option to do so.

·         False rejections of payments by the issuers, again this provides a terrible user experience and shopping cart abandonment.

 

Both of the above issues lead to frustrating situations.  Examples of these are when people forget their 3DS credentials, or when you call your bank to be told the rejection was because of the merchant, then the merchant says it was the bank!

 

In addition to this the upcoming EU rules on electronic payments authentication, how we verify that the person who is paying is the right person, are likely to add to this complexity.

 

These regulations are the Revised Payment Services Directive (PSD2).  They have three objectives: harmonization, innovation and security.

On security, PSD2 requires ‘strong customer authentication’ to be applied for all electronic payments in Europe.  Strong authentication in this case refers to using at least two of these three factors;

·         something you know such as a password,

·         something you have such as a card

·         something you are, for example, a biometric.

 

The EBA (European Banking Authority)  is responsible for the regulatory technical standards to deliver strong customer authentication.

 

The above issues and potentially increasing complexity leads to a poor experience and shopping baskets being abandoned.  This is due to either friction in the process or false rejections of payments by the issuers.

 

So how can this situation be improved upon? We need a solution that meets the needs of consumers, merchants and issuers as well as the intent of the proposed PSD2 regulations?

Breaking these down;

 

Consumers want a safe, seamless and reliable payments ecosystem.

Merchants want a safe, seamless and reliable payments ecosystem that maximises consumer spending and minimises fraud.

Issuers want a safe, seamless and reliable payments ecosystem that maximises consumer spending and minimises fraud.

The EU and EBA want a safe, seamless and reliable payments ecosystem that maximises consumer spending and minimises fraud.  Additionally they specify through PSD2 that we must verify that the payer is the correct person using ‘strong authentication’.

 

As you can see the needs of the majority of people in the payments ecosystem are basically the same, safe, seamless and reliable payments!

 

Can we solve this and provide a solution that will minimise fraud, improve acceptance rates while maintaining or improving the customer experience.  The short answer is YES.

 

By combining advanced authentication solutions with card details it is possible to provide strong assurance that a user and card are correctly linked and that a payment is genuine.

 

Utilising relatively simple code and an authentication solution fast enough to be in the online transaction flow enables us to reliably link a card to a device.  Note when I say device I include laptops / desktops as well as phones and tablets etc.

 

By doing this we can immediately identify multiple attributes about the card, device and behaviour such as;

  •  Have we seen this device and card combination successfully used before?
  • Have we seen the same name on a different card from this device before?
  • Does this behaviour align with previous successful payments from this combination such as volume, velocity, amounts etc?
  • Where were these payments made from?

 

This is in addition to all the traditional fraud analytics applied to the card behaviour alone.

 

3DS can still be incorporated if required, even with all this additional information.  However its use can be minimised by asking questions such as; 

  • Have we seen successful 3DS from this device and card combination within a predefined period? 
  • have we seen the same name on a different card from this device successfully authenticate with 3DS?

If so then trust this as if it was a 3DS payment.  This would enable the ability to provide the assurance of 3DS, while minimising it’s adverse impact.

 

This requires some innovation and for the issuers, schemes and processors to work together, along with the EBA recognising that this meets the intent of their proposed regulations.

What are the next steps?

Schemes and issuers, work with the processors to enable these benefits.  Accept greater assurances and risk based decisions from processors.  A higher payment acceptance rate and lower fraud, all with minimal effort clearly benefits everyone.

To the EU, EBA and those writing PSD2, engage in the discussion and realise there are ways to meet your intent without adversely affecting the payments ecosystem.  Intelligence and innovation can provide ‘strong authentication’ without the need for any extra complexity in the payments process. We can in fact reduce the friction while improving the security.

 

Everyone involved in the payments ecosystem wants pretty much the same things, let’s be innovative and achieve these in ways that improve the experience for merchants and consumers.  This ultimately improves things for everyone!

 

Feel free to contact me via this blog, or find me on LinkedIn to discuss further and if you’d like to know some more details around how this really can work in practice.

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

 

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

The password is dead, long live the password?

There have been many reports of the death of the password.

However the password remains the most common authentication method by far.  Indeed, many apparently forward looking organisations still rely on them for their staff and customers security.

Given the multitude of well published breaches caused by password hacks, and the number of stolen password databases it would seem like a no brainer for organisations to move to more secure authentication methods.

Indeed, as this article from a couple of years ago demonstrates clearly passwords are not very hard to crack;

http://www.wired.co.uk/news/archive/2013-05/28/password-cracking

Even if you think your password is especially complex..

Interestingly it seems many ‘free’ services such as Yahoo and Gmail are actually leading the way and trialling more secure solutions even if they are not as slick as they potentially could be.  So we have a situation where your free service offers you more secure authentication than many of the paid services you or your organisation may use.

If you have services that only offer passwords as an authentication, or if you as an organisation still only offer this, then please adhere to 3 simple pieces of advice.  And please make the effort to educate your colleagues and customers!

  1. Have the passphrase mindset, not password.  Length beats complexity so use long, but easy for you to remember passphrases.
  2. Use a variety of passphrases for different sites, so if one is compromised your other accounts are not
  3. Change them reasonably frequently, say every 90 days.
  4. Oh and as a bonus, don’t ever share them!

So while everyone seems to agree passwords are pretty poor from a security perspective, very few organisations are really working to move away from them in the near term.

Why is this?  The reasons I can think of are;

  • They are free and easy
  • Everyone sort of understands them
    • I say sort of because we know what they are but provably fail to create ones that are difficult to crack, we re-use them extensively etc.
  • While the broader public read about how bad they are, they still don’t really push for something better.
    • Or they just accept them as most companies don’t offer anything better so what choice do they have?
  • More secure solutions involve change
    • People and organisations are often scared of change
    • What will our customers think?
    • Will it be difficult?
  • More secure solutions will involve cost
    • Implementation
    • Licenses
    • Support / management

However I think now really is the time to start moving on this.

Ask yourself;

  • Does your organisation want to be in the news as the next one suffering a breach relating to passwords, whether cracked, social engineered or stolen?
  • Do you want to lag behind competitors and ‘free’ services as they start offering more secure authentication solutions?

In terms of offering more advanced and secure authentication solutions, there are many potential benefits to your organisation and its customers including;

  • Differentiation (for a time)
    • Get ahead of your competitors, be seen as a technical and security leader by offering very public security enhancements.
    • This will also help your reputation as an organisation that takes security seriously.
  • Less hacked / breached accounts
  • Improved security for you and your customers
    • Better security for your customers = better security for you.
    • It is also extremely likely that what ever solution you implement can be rolled our to employees as well as customers.
  • Improved analytics and understanding of your customer environment
    • Most authentication solutions are able to collect a lot of data around both the behaviour of users, and their environment (browser and device information).
    • This is especially true of those that support risk based authentication.
    • If your organisation collects data into a big data platform, then this data can further enrich that, enabling greater analysis of user behaviour, what good / bad looks like etc. (more on this in a later post).
  • Better customer experience
    • Risk and policy based authentication enables decisions to be made based on things like the users historical behaviour, device knowledge, and the action within the application they are performing.
    • This means that for lower risk, known activities from known devices the users interaction with the system may be entirely friction free for them.  ‘Step-up’ authentication can be applied when they step outside of normal behaviour, or want to perform higher risk / administrative type activities.
  • Staying ahead of regulatory requirements
    • Increasingly regulators are starting to require ‘strong authentication’ for customer interactions with an organisations systems.  This is especially true in areas such as banking and payments.
    • Implementing solutions now will save you a rush to meet regulatory requirements in the near future.

I hope from the above that my position on this is clear.. It is time to move away from relying on passwords, and there are huge benefits from doing so.

It would be great to hear from you and to get an idea of how many organisations are genuinely planning to implement more secure and innovative authentication solutions vs. those who frankly have their heads in the sand.

K

 

 

Extending the Perimeter

There are many articles covering ‘the borderless enterprise’ / de-perimeterisation and how the firewall and network perimeter are dead.  For the vast majority of enterprises I fundamentally disagree with this premise.

Most companies have and will continue to have a relatively well defined ‘core’.  This may anything from physical servers in a data centre they own through to a completely ‘virtual’ data centre in a public cloud.  What they all have in common is a set of servers / services and the associated business data that they really care about protect and have enforced rules around what and how things can connect to them.

Even in the supposedly de-perimeterised world of mobile and byod etc. the reality is that most business services will have rules around how they are connected to.  This can range from basic stateful rules that just define the network addresses, ports and protocols that are permitted but don’t do anything to interrogate the traffic that matches these basic rules, through to fully application aware Next Gen Firewalls and Web Application Firewalls that decrypt and inspect the application traffic.

I may to a further post on the subject of ‘the borderless network (or lack thereof)’ at a later date, but now I have outlined my position, that isn’t the main topic of this post.

Currently we have a situation where many companies / organisations have relatively secure, monitored and access controlled core systems that house that the bulk of their data and systems.  However how many organisations consider the security of the devices, browsers and apps that connect to them?

For me this is a clear gap in the majority of organisations security posture!

How many attacks come from compromised devices / browsers / apps connecting to organisations networks?  How much fraud occurs due to compromised end user systems that could be prevented if the compromised systems were detected?  How many attacks or fraud from malicious users could be spotted if the malicious use of the application or malicious tools being used could be alerted on? …

Considering organisations whose customers run their business through mobile or web applications how much more engaged would you be with your customers if you could alert them that their system or application / browser may be compromised?

For these examples, plus some further thoughts I’m currently investigating various ways we can monitor in real time the condition of any web browsers or mobile applications that connect to an organisations web facing systems.  These solutions involve inserting code into web pages that analyses / interrogates browsers, and code in mobile applications that analyses / interrogates the application and mobile device.  They also have various other features such as checksumming the code / application, using PKI for in app / browser encryption, and device fingerprinting.

I think solving this transparently to the end user will drive security insights, improve an organisations security posture and potentially enable closer ties to and trust from customers.

These solutions when linked to some of the current trends in authentication such as geolocation and behaviour analytics can be combined to provide security analytics of a quality far above that which is usually available.

What do you think?

Feel free to contact me via this blog if you’d like to discuss this further or share your thoughts on the security of devices connecting to your organisation.

K