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

Why does the OWASP top 10 never change?

Or very rarely?

Subtext, how should we work to create more secure applications?

The OWASP top to remains largely unchanged over long periods of time.  We still see high profile breaches like Talk Talk caused by easy to protect against application attacks.  These fact imply many organisations are still failing to do ‘application security’ properly.

So why is application / development security so hard?  OR is it?

I think application security has historically had similar problems to other areas of security.  It is not seen as a business imperative, so business needs, new features, meeting client requests etc. all supersede security requirements in the priority list.

For many of us this is clearly not news.  However, given the number of incidents that still occur, it is clearly not a problem that has been solved.

For me solving this falls into 3 key areas;

  • Board level buy in for security, and specifically security throughout the development lifecycle – SDLC (Software / Systems Development Lifecycle).  This will ensure there is support for the costs and time associated with delivering a secure development programme.
  • Buy-in from the development teams.  Work with them to ensure they understand the reasons for, and benefits of secure development.
  • Making security part of the SDLC, by ensuring that the relevant tasks and processes are embedded as part of the standard lifecycle.  This will also ensure they are audited as part of that process.

I’ve spoken about board / exec by in for security before, and will do again.  There will also be another post in this series covering developer buy in as that is key to the process being successful.

The rest of this post will cover the areas that I think need to be covered in through the process in order to ensure the development process is as secure as possible.

Where these steps fall, how they are implemented, and how they are checked / monitored will vary from organisation to organisation.  They will also depend on the development processes in place such as Waterfall and Agile variants.

At a high level, these steps are;

  1. Requirements including security requirements
  2. Secure designs
  3. Threat modelling
  4. Static code analysis
  5. Peer code review – focus on quality and maintainability not just ‘pure’ security
  6. Dynamic application analysis / web application scanning
  7. Penetration testing
  8. Associated processes – found flaws are fixed at each stage of the process
  9. Clear risk assessment and ownership processes
  10. Developer Training

 

Requirements, including security requirements.

Any project must have some requirements.  These are what enable us to answer the question ‘what problem am I solving?’.  This also applies to BAU (Business As Usual) type development that may not fall under the project processes.

These requirements need to include the non-functional areas as well, of which security is one.  Security requirements should be as standardised as as much as possible to minimise the effort, and tailored as part of any project or work initiation phase.  To support this, ensure your application security team is closely embedded with the project teams, business analysts and developers.

Secure Designs

While this is more of a statement than process, I have included it to highlight that security teams need to be involved throughout the design process.  I would also recommend that security should be an approver of system and application designs.  This will ensure that meet security policies and requirements as well as meeting secure design principles.

Threat Modelling

This is the process of reviewing a system and assessing any potential threats to it, along with how to counter those threats.  The earlier in the process this can be accomplished the better as it allows the designers and developers to work with the potential threats in mind.  Although either an existing system, or at least a high level design is required to make this worthwhile.

I am personally a huge fan of threat modelling as it has multiple benefits for relatively low cost / effort;

  • More secure designs and development as the teams working on the solution will have a better understanding of the threats, and how to counter them.
  • A better understanding of the system, one of the artefacts from threat modelling is the DFD (Data Flow Diagram).  How many systems in your organisation have have detailed DFDs?  This fills that gap.
  • Under the radar security awareness training.  Without labelling it training, the security team gets to spend a decent amount of time with the design and development teams talking about threats to a system, the consequences if these threats are realised and how to protect against them.

Static Code Analysis

This is the use of a code analysis tool the performs automated scanning of the code and / or binaries for potential security weaknesses.  Good tools also provide remediation guidance for the discovered issues and a workflow for assigning the issues and documenting how it will be remediated or mitigated if your don’t already have a tool for this.

These tools will integrate with various development environments and source repositories, along with different development processes.  If you are not already using one I would recommend performing an analysis of the key players in the market to assess the best fit for your environment.

Peer code review

This is the process of ensuring different developers assess each others work.  This should include cross team assessments with a strong focus on code quality and maintainability as well as security.

Encouraging this process to be as open as possible, to enable open debate about the best way to code will definitely be beneficial.

While code quality may not be strictly a security concern in the traditional sense, the better written, commented and maintainable code is, the easier it will be to maintain the applications security over the longer term.  This is especially true as it is developed and worked on by multiple people and teams.

Dynamic Application Analysis / Web Application Scanning

Similar to the static scanning, this will be an automated process, carried out using a scanning tool.  This is the process of assessing a running application for security vulnerabilities.  These usually focus on areas of user interaction such as web pages so will not be suitable for all systems.

The need for a running system means these scans fit later in the process than the static scans, and usually fit well through the testing phase of any project / development work.

It should be noted that while these are more effort than static scanning, they should be considered especially for larger or more critical systems as they will find issues earlier and at a lower cost than pen testing, thus ensuring less issues are found later in the process.

Penetration Testing

This is the process of dedicated professionals, usually from a specialist third party attempting to ‘hack’ the solution.  This is usually the final check from a security perspective that a piece of development or an application is secure enough to go live.

Due to the costs and efforts involved it is likely that you will want to haver a clear process in place for when and how often pen tests are required.  Depending on your industry there may also be minimum regulatory requirements around how often systems are pen tested.

Associated processes

I have included this as a catch all to highlight that all of the above processes need to have agreed and working feed back loops to ensure the items they identify are assessed and remediation agreed.

Risk Assessment and Ownership process

Following the above point, and discovered vulnerabilities that cannot be fixed or mitigated will lead to a risk to the organisation.  This must be formally assessed in terms of the level of risk, and then accepted for an agreed period by an appropriately senior business owner.  The risk process is an entire topic of it’s own!

Developer Training

I was not sure whether to put this at the start or end of the list as it must be an ongoing process outside of any specific project or development work.  As well as ensuring that your developers have approbate levels of secure coding training, this should be seen as a key part of your engagement with the developers and getting their buy-in for secure development.

Depending upon the size of your organisation I would recommend a combination of on line computer based training (with a programme to increase the skill / knowledge on the courses over time and dependant on the experience of the developers), workshops and presentations from external companies, including pen testers.  For larger organisations secure development forums and ‘conferences’ could also be considered.

 

While nothing is completely secure, especially as complexity increases, if you follow these steps as part of the process you will end up with applications that are definitely not the ‘low hanging fruit’.  This will reduce your risk of any application related breach.  In addition it will mean that should you have a breach your organisation will honestly be able to say that they had done what they could to ensure secure applications, and the protection of the data you hold.

As final thoughts for today’s post, do not take these in isolation, this only covers the application part of your security, all the other key areas from network security to JML (Joiners, Movers, Leavers) processes must be in place to ensure an appropriately secure organisation.

K