Be careful with security exceptions

Last weekend I had an incident with my bank card and I found out that my card had been stopped by my bank 'because of a potential compromise of secured data'. After some digging I found out that somehow my card number had been leaked or the data had been compromised by my bank.
Now this alone is bad enough but what I was told next was worse. I was told that the bank would have contacted me to verify transactions against my account if they had my phone number.

This gave me pause for thought. The bank would have phoned me up and asked me to confirm transactions against my account.

"How would they have know it's me?" I asked, "Oh that's simple Sir. We would have asked you some security questions" he replied.


"How do I know that it's actually my BANK calling and not some stranger trying to compromise my data?" was my next question.


I went on to explain "You ask me security questions to validate that I am who I say I am but I how do I validate that YOU are calling from the place you say you are?"

After some struggle he said that they could confirm they were from the bank by getting me to confirm some transactions but after more pushing he admitted that BEFORE they confirm any transactions they would need my security data.

The upshot of this is that I am expected to give out my confidential security data to a total stranger who may or may not be from my bank. I have no way to verify they are who they say they are.

There is one way the bank could prove it's them contacting me but the person on the other end of the phone never thought about it and neither did I until afterward. I'll leave the validation process as an exercise for the reader!

This whole exchange got me thinking about setting security standards then requiring exceptions that blow those standards out of the water. The classic is the faithful password. We are told time and again that passwords should NOT be revealed to anyone yet I know of one ISP that requests your password as a SECURITY CHECK, OK you have called them but it still promotes bad practice.

In any security configuration you are going to need exceptions, e.g. if your policy stats that all passwords expire once a month you will need exceptions for service accounts. The key to a good security policy and good security practice is to make sure those exceptions are well documented, well understood and sensible. To set a policy and then have a practice that routinely violates that policy is worse than not having one in the first place.

Author image
IT Person | Veeam Vanguard | VMware vExpert | Windows admin | Docker fan | Spiceworks moderator | keeper of 3 cats | Avid Tea fan