Sales:          sales@esecure.com.au
Careers:      jobs@esecure.com.au

LinkedIn Logo
Facebook Logo
Twitter Logo
GlobalMark Seal
CREST Australia and New Zealand Logo

e-Secure Pty. Ltd.

ABN 48 086 248 419

Copyright 2019 e-Secure Pty. Ltd. All rights reserved

  • Clinton Smith

CSX - Customer Security eXperience

Updated: May 15, 2018

As a long serving member of the Security community I have witnessed the evolution in how security has been managed, and offer some predictions on where Customer Security may be headed.


Lets first start with an overview of the evolution of the role of the IT/Information Security team.


1. The Policeman - uphold the law


In the late 80's the role of security was to understand and rigorously enforce an organisations policy.


This led to sophisticated desktop, network and other forms of monitoring, which were coupled with education campaigns to prevent people from doing the wrong thing while in the workplace.


It was the day of the bad email joke being forwarded from person to person within an organisation like a secret society.


The Security team would usually be engaged in a project as a frustrating last resort, were feared (and sometimes loathed) and usually considered optional.


2. The Priest - advise and guide


Mid 90's came a shift in the thinking about security, less focus on detection, more on prevention. It was an era of more common Internet access and with that came new issues such as the pornado. A myriad of new technology solutions such as software with skin-tone and key-word detection.


The Security team started to shrug off the mantle of "Internet Police" and very occasionally began to get engaged in the tail end of activities as a "Perhaps I better get a security person to look at this new Banking platform before I connect it to the Internet" style of discussion.


This was also the age of the software developer (often the arch nemesis of the security team) conversation such as "nobody will ever hack this platform, it just does not happen", "you are such a zealot! - why should I force users to have a password" and "turning on antivirus slows down the system, so we are leaving it off"


3. The Weather forecaster - help us avoid the tornado


Still disappointed that the Y2K did not see the realisation of their predictions of doom and devastation, security issues started to become more mainstream, the Security team started to get earlier engagement and began to provide useful advice earlier in a project or activity.


Some stakeholders even discovered that due to their multi-disciplinary background many security people could be engaged to help troubleshoot their application and network performance issues. "Your intrusion detection system is making our application unusable, you will have to fix it or we will turn it off"


4. The insurance policy - help us to sleep better at night


From 2005 the data breaches started to get bigger, the attacks more sophisticated and the targets much broader. Industry and society as a whole started to become much more aware of the problem of connecting legacy operating systems, poorly designed applications and open networks and devices to a Public, nearly anonymous network.


The amount of time it takes (a few minutes) for an unprotected computer to become infected when connected to the Internet has been tracked over time and is a sobering statistic. Having security expertise (either in-house or on-demand) is now often the difference between business as usual or disruption and data breaches.


_______________________________



Throughout all of this change, both in terms of the threat of cyber attack and our approach toward it, there were often casualties - our Customers.


Some examples of technology solutions which frustrate customers and have (in themselves) only marginal security and risk benefit. (aka Santa's security naughty list)


1. Human Tests

Often for the best of reasons (such as preventing automated scraping of content on a website) well-meaning website owners started to implement ever-increasingly-cryptic human tests.


One of the best known 'CAPTCHA' would challenge visitors to the website to interpret a sometimes unintelligible swirling jumble of letters and numbers.


2. Floating keyboards

In possibly one of the most frustrating security mechanisms (aside from having to take shoes off at an International airport), the floating keyboard emerged on some prominent Australian websites (you know who you are).


3. The necklace of tokens

Whilst for some, jewellery is an important fashion accessory, I am yet to see a necklace made from physical security tokens. Carrying around pieces of plastic and digital devices is both cumbersome and they lend themselves to be lost or stolen.


Many building access cards are able to be cloned or copied without a person even being aware, making an attack to subvert building security trivial (this would be a concern if it weren't for the fact that far easier, lower risk options to gain access to buildings exist).


4. The insanely complex password

Some websites force their customers to use the most cryptic passwords with no real consideration of the real value. Complexity settings are typically intended to stop password guessing.


Given the prevalence of phishing and malware, coupled with website vulnerabilities, forcing customers with compromised computers to use a complex password could be considered lipstick on a farm animal.




Whilst the above security measures do not meet the criteria for security theatre, their value in risk mitigation may arguably be outweighed by the customer experience they provide.


Good Security does not have to be overt, and should be designed-in, unobtrusive and address the actual threat or risk it is designed for.


I feel it is time for us to add the human centred design component back into security, hence the term CSX or Customer Security eXperience.


Security measures should therefore also include consideration of the following:

  1. Does the issue, risk, or requirement actually warrant a security measure? (or does the control actually introduce a greater risk)

  2. Does the security measure actually address the real problem (risk, obligation)?

  3. Does the security measure meet both its risk mitigation and usability criteria?

  4. Does the security measure address the most likely risk / threat, and is it the best option?

  5. Is the security measure simple, seamless and well designed with no assumed security expertise?

  6. Have we road-tested the security measure with real people (not just security researchers)?

  7. How does the security measure make a Customer feel (frustrated, protected, confused)?


Contact us for help in improving your internal or external Customer Security eXperience.


Author: Clinton Smith

31 views