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


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


Developer engagement..

Following my recent posts covering application security and patching, another recent hot topic of conversation has been around developer engagement.  Specifically how to ensure developers are fully engaged in the secure development process.

Much like many current patching processes an issue with a lot of secure development programs is that they are still very ‘push’ focussed.

This approach can be successful, especially for organisations with less security maturity.  I have personally seen great uptake in the use of secure development tools and processes through my current teams work.  However while taking the ‘push’ approach can dramatically improve your application security processes, it does have limitations.

These limitations include;

  • It is very resource intensive for the Security Team – they constantly have to ‘push’ to get developers using the tools and processes and on-boarding new applications and developers etc.
  • It can lead to a culture of secure development being the responsibility of the security team rather than the development teams – a culture of taking rather than owning security
  • Things, including entire applications can be missed.  The security team can struggle to know every application and development project that is in the environment if the onus is on them to push security to every application.  This is especially true in more complex, multinational organisations
  • This focus can also lead to dissatisfaction and higher churn in your security team as you will have skilled application security professionals spending large amounts of their time on-boarding developers and applications, and chasing development teams to understand what is being worked on

So, how can we fix this and ensure the secure development practices from training through threat modelling and code reviews are embedded into the development process?

If you read my post on patching, my key thought will not surprise you!  Developers and development teams need to have responsibility for secure development as one of their key objectives.

This is a fundamental shift in culture and responsibilities.  In order to be successful you’ll need to work to drive support from executives as well as the development teams and their managers.  However if you can enable this culture shift, you will have made a huge difference to the uptake and success of your application security programme.

This shift will change the responsibility for ensuring developers are enrolled on the training platform and added to the code analysis tooling into the development teams.  It will also drive the use of the security tooling as one of their key objectives.  There are two key benefits of this approach;

  • Coverage; The development teams and their management will be bought into the benefits and requirements for security.  This will drive the use of security tools and processes for all in scope developers and applications.
  • Enterprise security can focus on security.  The skilled application security specialists in your team will now be able to focus much more on working with the development teams to support secure design and coding.  The secondary benefit of this is that your team will be more engaged doing the work they want to rather than chasing developers to on-board them and their applications!

The second thing I would recommend to support this approach is the creation of ‘security champions’ within the various development teams.  This would likely not be a distinct role, but rather existing developers who ideally have an abiding interest in security.

These roles will have the responsibility of having a strong understand of the required security processes and tooling, along with fostering a close working relationship with the application security team in enterprise security.  These roles could also help with the development of secure coding guidelines and ensuring the application security team understand the way the developers work and challenges they face.

To support the role and working relationship, security champions having ‘dotted line’ reporting to the application security director (or equivalent) should be considered.

The final piece of the puzzle is to ensure your application security team understands the various development processes in use across your organisation.  While the same level of engagement, similar tooling and processes will be used regardless, how they are applied is likely to vary considerably across different development and support styles.

To be successfully integrated the application security team must consider how to best integrate with Waterfall, the various ‘flavours’ of Agile, DevOps etc.  While you do not want a million different processes you’ll likely need a few to cope with the different development and project processes.

If it is not yet in place for your organisation, a good starting point for the SDL (Secure Development Lifecycle) and the steps it should contain is the Microsoft SDL

To help you consider variations of your process for different methodologies they also have an agile version;

Let me know what you think of these ideas, and how you get on with implementing them on your organisation, if you are not doing so already!


Who is responsible for patching?

Midweek rant.

How many times have conversations along the lines of;

‘we are waiting for security to tell us what to patch’


Why do teams responsible for running and maintaining systems persist in making patching a security issue?

I would challenge this and go as far as to say it is fundamentally wrong.

Patching / maintenance / updating systems must been seen as a core part of running a solution.

No solution should ever be deployed into a production environment without a clear ownership and agreed processes for maintaining it.

The role of the security team should be to provide assurance that the environment is being patched etc. according to the agreed processes.


This would change your weekly / monthly patching / vulnerability management meetings from ‘here are all the patches that are past due and must be applied’ to ‘great job guys, 90% of patches applied lets discuss the few outliers’.

Also what happens with all the non security patches in these environments? Are they ever applied? how are systems kept up to date?

So – Maintain you systems. Patch them.  Keep them up to date. Let security provide assurance that this is happening.  Simple.

This approach also allows people to spend a lot more time working on the hard security problems rather than spending half their life talking about why patching has not happened!

A slightly blunt one, but I strongly believe this move in responsibility and accountability must occur if the patching crisis is ever to be resolved.

The next post will be back to the range of topics I have been discussing recently.



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;

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.


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.


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.


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!


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.





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;

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.




2016 Resolutions. The detail..

As promised, this follow up post will outline what I mean by each of the ‘resolutions’ I highlighted.

These were;

  1. Patch.  Everything.  On time.
  2. Protect your hosts.  Do application whitelisting.
  3. No admin rights for anyone who can access production data.
    1. No one with admin rights can access data.
  4. Role Based Access.
  5. Segregate your networks.
  6. If you create code, do solid code assurance.
  7. Test and Audit.


1. Patch.  Everything.  On time.

Sounds simple right?  It should be, but it seems it isn’t in many companies.  From my experience there seem to be 2 main drivers for so many companies failing this most basic of maintenance tasks;

  • Systems that must have almost 100% uptime, with no, or ill defined patching windows and processes.  This goes hand in hand with these solutions being incorrectly designed, if a system must always be ‘up’, design it in such a way that components can be taken out of service to be patched and maintained (or indeed if they fail).
  • Incorrect ownership and drivers for the patching process.  In many organisations it seems to be the security team who drive the need to apply ‘security’ patches.  This needs to be turned around.  Any system in production must be patched and maintained as part of BAU.  Systems / solutions should never be handed over into production without clear ownership and agreed processes for maintaining them, this must include patching.  Security then become an assurance function for this and their scans / checks confirm that the process is being correctly followed, plus of course highlighting any gaps.

If you see these issues in your organisation, make 2016 the year you address them, don’t be the next business in the headlines that is hacked due to systems that have not been patched for months!

2. Protect your hosts. Do application whitelisting.

With the ever more porous nature of our networks and perimeters, coupled with the insider threat and phishing etc. protecting our hosts is becoming ever more critical.

AV (Anti Virus / Malware) is not dead, but it also clearly is not enough on it’s own.  Indeed you will struggle to find any host protection product that only does AV these days.  Ensure all your hosts, both servers and user end points are running a solid, up to date and centrally managed host protection solution (or solutions) providing anti malware, host IPS (Intrusion Prevention System), host fire-walling and ideally FIM (File Integrity Monitoring).

I’m gradually trying to change peoples language from AV / Anti Malware to Host Protection as I think this covers both the requirement, and many of the solutions far better.

In addition to this I would strongly recommend the use of an application whitelisting solution, as this can provide a key defence in preventing any unapproved (or malicious) software from running.  As well as preventing malware, these solutions have the added benefit of helping to maintain a known environment, running only known and approved software.

3. No admin rights for anyone who can access production data.  No one with admin rights can access data.

This is something I am currently championing as a great way to reduce the risk to your organisations data.

This may be harder for very small organisations, but for medium and larger ones, think about the different roles your teams have.

How many people who need to access key data, e.g. via production applications, need to have administrative rights on their end user systems, or on the production systems?

Conversely, how many of the system administrators who maintain systems and databases etc. need access to the actual production data in order to perform their duties?

One of the most common ways malware gets a hold is via users with administrative privileges.  So if we prevent any user with these elevated privileges from having access to data, if they or their systems are compromised, the risk of data loss or of damage to data integrity is massively reduced.

While it may seem a substantial challenge to prevent administrators from having access to data, there are at least a couple of obvious options.

Some host protection solutions claim to have separation of duties capabilities that control who can access data outside of just relying on O/S (Operating System) permissions.  I have not tested these though.

Various companies offer transparent encryption solutions that have their own set of ACLs managed independently from the O/S permissions.  These can be managed by for example the security team to ensure only approved business users can access data, while still permitting administrators to perform their role.

4. Role Based Access.

This one should hopefully require minimal explanation.  Each type of user should have a defined role.  This should have associated system permissions allowing them to access data and perform the tasks required to perform their role.

This ensures people should only be able to access data they are supposed to, and not data they should not.  The principle of ‘least privilege’ must be adhered to when creating roles and applying permissions to ensure everyone can perform their duties, but not carry out tasks outside of those that are approved.

This can be backed up by using some form of IAM (Identity and Access Management) solution.  Although be careful about over complicating this if your organisation is not large enough and complex enough to warrant a cumbersome IAM solution.

5. Segregate your networks.

In addition to external firewalls preventing access from outside your organisation, internal networks must be segregated as well.

When designing your networks, think carefully about which systems need to to talk to each other, and on which ports.

For example, do your end user systems all need to access all of the production environments?  Or do some of your teams need access to some production systems and only on specific application ports?

This point can be linked with the host protection one above as host firewalls can be used to further prevent unauthorised access to systems.  Most servers do not need to connect to all other servers in the same zone as them.  Host firewalls can be used to restrict servers from connecting to other servers they do not need to, without requiring an overly complex network design.

Strong network and system segregation will help prevent the spread of any malware or malicious users within the organisations’ IT estate, and thus help ensure data is not removed or changed.

6. If you create code, do solid code assurance.

The OWASP top 10 has changed little for several years (look it up if you are not familiar).  Applications consistently have known and well understood vulnerabilities.  These same vulnerabilities are consistently exploited by malicious people.

If you create applications ensure the code goes through rigorous manual and automated code reviews.  Ensure the application is thoroughly tested against not just the businesses functional requirements, but also the non functional requirements from the security team.

Finally, before the application or substantial change goes live ensure it is penetration / security tested by experts.

Performing all these checks does not guarantee your application cannot be hacked, but it will ensure that it is not an easy target.  Ideally these steps should be key and non negotiable parts of your organisations SDLC (Software / System Development Life Cycle).

7. Test and Audit.

Once you have the basics in place, you need to ensure they are being successfully applied.  This is where the assurance part of the security teams role comes into play.  Whether it is supporting the SDLC processes or scanning systems for outstanding patches, the security team can, and must, assure that the agreed tasks and processes are being adhered to.

This step is critical to the ongoing success of the previous items, the effort and expertise required to complete it should not be under estimated.


Hopefully this has supplied some clarity and context to my previous post and made my intent clear.  Let me know.

In some following posts I’ll start talking about some of the really fun and intelligent things you can start doing once the basics are in place!


2016 Security Resolutions

It’s that time of year again, everyone will be writing their resolutions and predictions for the year.

Will we have more of the same?  More APTs?  More nation state sponsored breaches?  DDoS?  Increased application attacks?  More mobile malware?


We all know there will be hackers, criminals, hactivists, malicious insiders, nation state actors etc.  We also all know there will be application attacks, malware, APTs, DDoS etc.

Rather than write another predictions article I thought I’d try a slightly different tack an cover the key things I think every organisation MUST do if they are not already.

  1. Patch.  Everything.  On time.
  2. Protect your hosts.  Do application whitelisting.
  3. No admin rights for anyone who can access production data.
    1. No one with admin rights can access data.
  4. Role Based Access.
  5. Segregate your networks.
  6. If you create code, do solid code assurance.
  7. Test and Audit.

Get the basics right!  There are of course many other things to focus on, but hopefully the general idea is clear.  Organisations need to be mindful of throwing too much time and money into the latest and greatest APT protection, behavioural analysis, and overcomplicated solutions to simple problems.  Getting the basics right must be the first priority.

Remember, it is extremely likely that attackers will go after the low hanging fruit.  Even if they are  directly targeting your organisation, it is un-patched systems, people with admin rights and unprotected hosts or applications that will be attacked first.  Only after these avenues have failed will they resort to more challenging and advanced attacks.

I’ll use a follow up post to cover the above point in more detail, but wanted to get these initial thoughts up.

What do you think?  How is your organisation doing with the basics?  Do you spend too much time on new, sexy security when you don’t have the basics covered?

Happy new year all!




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.


FireEye Technical Briefing 19th March 2015 part 2

Ensuring Security is a boardroom imperative

This is a topic I’ve mentioned before, for security to be successful in a business it must be discussed, understood and supported at a boardroom level.  The below notes from this talk highlight some thoughts that very much align with my own around how we need to engage with the board to gain their buy in for security and security initiatives;


Security must be discussed with the board in business terms that they understand.

– need to consider your audience

– where do they get their knowledge from – e.g. non expert media and audit partners

– Consider things like Financial Integrity, Human Capital, Cash Flow Stability, Operations, Growth opportunities etc.


Educate that Compliance is not Security!


This is an absolutely key point for me, not just in relation to the board, there is often a perception at all levels of the business that meeting a compliance requirement equals security.  While there is definitely a place for regulations and compliance, I have had so many conversations where there is a push back on doing security right as a half way ouse to meet compliance requirements has already been planned or implemented.

My take is – Do security right and you’ll largely achieve complaint as well.  Do compliance and you will not be secure.


Do we understand their risk appetite?

– Do they actually know their own cyber risk appetite?

– Do they know how much cumulative risk they are carrying?

– These conversations need to happen..


Its about appropriate level of security.  Detection and incident response are key – you may / will be breached so this focus is critical.

We can’t deal in absolutes, it is about risk reduction and breaches being inevitable.

– Executives need to be brought on board with this mind-set.


Today’s Security paradigm;

– Breaches are inevitable

– Cyber security is mission critical, yet non core for the vast majority of organisations

– Your processes and response procedures must stand up to external scrutiny

– Security is a business risk issue, not a technology problem

– You need partners, not just products


Notes about current attacks;

– They are targeted

– Across EMEA, frequent attacks consistently seen in UK, Germany and Saudi Arabia – 5 countries account for about 60% of all attacks seen in these regions

– 4/5 of the largest EU countries by GDP are attacked across many verticals

– Government and Financial Services are targeted – 50%+ of all attacks across just 3 verticals


Spend is not a proxy for security.

 – Must do things right and have good processes as well as ther correct tool set


Security is like chess – complex but with a finite set of ‘moves’ – and remember the best people can still beat computers at chess!


Even if you do things right you may still be breached.

Need to raise Cyber Consciousness – guide your execs to quality reading and reporting, base on knowledge, not fear.

We must manage expectations, and define the win – base decisions on sound business rationale – such as the TFL DR plans for if Oyster compromised during peak times like Olympics or key football matches; These involved just opening the gates in the event of an issue and taking the potential hit for that day rather than interrupting key events

Successful Organisations…

– Don’t have changing stories – if breached be honest and consistent

– Can demonstrably prove diligence in responding to an attack

– Can articulate why we failed

– Are typically not afraid to talk about what happened in a more transparent way that builds confidence

– But need to be mindful of legal framework and ramifications

– Don’t take 200+ days to find an attack!

– Don’t wait for others to tell them about the attack – use good threat intel etc.

– Don’t let others control the disclosure

– Are able to withstand 3rd party inspection


Be bold, engage with your executives in terms they understand, do Security not Compliance, have great processes as well as tools, using intelligence and have great monitoring and incident response!