Over the last year or so, it has become increasingly obvious that there is a uniformity related to technology failures, and more than one would be expected to encounter.
In this case, I am looking at this through grey tinted lenses, which reflect the grim circumstance of cyber reality. However, prior to delving into the grimy depths of this subject, I would like to clarify two facts of life, which are as follows:
- It is not the technology that is at fault (no matter how intelligent it is claimed to be – it is after all dumb). The operational issues encountered in the majority of cases are very much down to those who plan (or don’t), provision (or don’t), test (or don’t), secure (or don’t) and implement such systems to accommodate live operational facilities.
- These circumstances of poor implementation and provisioning can be either part, or fully responsible with their support of security breaches, compromises and hacks, and this – for the security professionals, does serve to satisfy an ever present opportunity for employment (so, it’s not all bad news).
To start the conversation off, let us consider the average SAP deployment, with the accompanying lashing-up of multiple systems, interfaces, and integrations, which can be creations under the ownership of multiple support teams who do their best to work as one.
However, as anyone will know who has worked in such technologically challenged worlds of commerce, SAP can represent a model which does at times struggle to deliver what the tin says, and along its way, strives to meet the demands of the business, leaving out that annoyance of security, somewhat left standing in the wings. This is the subject of many hacker discussions who have identified that around 95 percent of SAP deployments are exposed in some way to the potential of compromise, exploitation, and hack – an observation I can concur with.
As further testament to this unholy alignment with the dark-side of opportunistic manifestations of insecurity, I reflect on the discovery of the Plc, who had gone to great lengths to sensibly lock their temporary staff, and contractors alike out from their server assets storing sensitive financial and client data.
However, they failed to apply this same rule to the temporaries and contractors who were provisioned to use VPN facilities to RAS in – who were, for some reason, the only known architects of this estate of servers, able to populate their remote desktop with the entire landscape of internal systems, and their stored objects – most of where were not subject to any level of adequate ACL, event logging, or even any malware/virus protection!
But let us not dwell too much on the potentials of internal compromise, but look out into the macro community of the public facing interconnected world in which much misconfiguration can, and does, also exist.
For instance, take the case of the international online bank account, which was set up for a client. In this case, the concerned user was sent a letter along with their account details and login password to facilitate their access to their funds. However, whilst the account credentials were recognised by the system, the second level of authentication required them to respond their provided security questions, each one of which failed in secession.
Even after multiple attempts to ‘have-a-go’ at signing in, the account was still not locking out even after 11 attempts! But then our user thought it may be something to do with the associated card to the account, and called the online service to assure it was activated. Upon connection, the recorded voice requested the caller to input the 16-digit card number – and upon doing so, the very same voice responded that ‘The number is not recognised’ – a message which was received a further 5 times prior to our user giving up in complete despair.
So, all-in-all, a very worrying, and uninspiring journey to gain access to what was, supposed to be a brand new provisioned and active account – a complete case of ‘Computer-says-NO’!
You may have also seen some conversations online, and in the press of late re some online gambling Help-Desk who had changed a user’s password based on them providing just two pieces of information, one of which was their user ID, and the other, one of those mundane and obvious questions, such as address, mother’s maiden name, etc. (all of which are very easy to obtain, without even breaking a sweat to conduct any social engineering).
That said, in the case of some online companies in this field, they are well versed in the world of insecurity, so possibly on occasions where such organisations add insecurity by inference to their curriculum vitae, we should be expectant, and progress forward on a basis of buyer beware.
This then brings me to that old, long-established habit of sending user ID, and passwords via an open email relay – really not much more to say on this subject other than, it is far too common, and has been proven to be a responsible agent in a number of events which has seen the provisioning of illicit access to another’s legitimate account.
And now we are getting right up-to-date with an event which implicated a user of a very well-known high street bank. In this case, our user was sucked into a scam concerning the purchase of a motor vehicle from Spain. Post shaking the electronic-hand on the deal and putting funds into the transaction queue, the prospective buyer realised some gut-feel reservations, and called their bank to express their suspicious that this could be a fraud in progress.
But as the transaction had not taken place, the fraud department of the bank in question was of the opinion that the suspicion was unfounded and took no action, and assured the buyer all was well. However, the car never arrived, and even more frustrating, had the bank in question took the trouble to look at the associated and accessible artifacts re the website of the seller, and the international transporter, they would have noticed two very obvious indicators to fraud:
- They were different companies, but the website was owned by the same person!
- The sites had only been active for a matter of months!
Unfortunate for the user their £14,000 investment in their new car never materialised with the goods. And as if to add insult to injury, the bank took no responsibility whatsoever, and so our user in this case, took the ultimate financial brunt of the loss.
My own opinion of the way systems are run, and security is conducted in our current age of cyber adversity is, it can be rushed, with an approach of ‘lights-on-is-King [and Queen]’, and when it comes to security, by evidenced fact, it would still seem to be a poor relation sitting in the passenger seat whilst shouting at the driver ‘STOP’– but that said, whilst losses can be adjusted out of a financial slice placed on the bill payer, it looks like the ultimate looser will always be the public, and commercial user in our current climate of cyber-irresponsibility.
The final observation in this article is to map the association between technology and what can be real impact on people’s lives and their families. In this case, we look at a case involving a public authority who, whilst migrating their payments system over to a new platform, actually managed to royally screw up both the old and the new, leaving them in a situation that dictated the only fall-back position was paper-based, and a back-to-basics approach to both resolve, and pay their accounts.
However, the real human impact here was, given a high number of the impacted individuals, and small traders were not in the high-earning bracket, suffering a wait-time of up to six months saw many of them suffer significant hardships. And given a number of these affected people were dependent on the authority for all of their work (painting and decorating, etc.). They did not wish to kick up too much dust for fear of retributions – but sadly, in some cases, and not for the first time, the old bite of cash-flow actually caused some small traders to go into liquidation – a situation that has not been uncommon in the past.
It is in such instances as this where I feel the element of empathy needs to override the matters of technical failures. After all, as I said, here we are dealing with real people, their livelihood, and the ultimate levels of stress such situations bring to the home front – totally unacceptable in anyone’s book, I hope. Thus, when it comes to the frustrations of poor provisioning of accounts, care and facilities offered to the user base, I consider it a reasonable request and expectation to at least assure what is being provisioned works, and has been fully tested.
Again, it would seem the bottom line is we have become that society which has fully embraced technology to drive everything possible, which at times can be completely devoid from any human in the chain of client-to-business interface. It would also seem that the anticipated levels of skill which are expectant in the supporting communities are not always present, and thus the shadow of system and application failure rise even higher on the horizon.
But prior to me signing off as the Dark Spectre at the feast, there is even more bad news, which is, based on the successful model of companies like Google, who have gained much financial reward out of other people data. Here we are now seeing many companies jumping on the same bandwagon by deploying apps, or services from which they also seek to value add their revenue-stream by facilitating on-mass exfiltration of client data under their very noses via the communication channel of their paid for broadband services – which in some cases is on a daily basis.
Someone once said (I think it was ‘I’) security and privacy are very unusual bedfellows but I think I was somewhat off-line and missed the other angle. What I should have said is, ‘Privacy and Insecurity are well established sleeping partners’ – a fact of life we all need to embrace in order to manage our own expectations of what we do, and what we don’t get.
In other words, expect to be disappointed, and your wish will be granted.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.