Psychology in Security - Impact of Bad Banking Processes

Quite a few of my recent posts have had to do with visits to the local bank. This morning I made a quick trip to the local branch to carry out some wire transfers. So I sat down at the Foreign Transaction counter and was asked for the following:

• Form providing details of wire transfer, amount etc. (no problem)
  
• A proof of transaction, i.e. an invoice etc. (ok)
  
• A blank cheque, with nothing but my signature/stamp on it. Nothing in the to field, nothing in the amount field. (WHAT!)

At this point, I couldn't help stare the bank employee in the face with the most ridiculous look and inquire about whether they also encourage customers to fund Nigerian officials in need.

Eventually after realizing that I didn't have much of a choice and adding a "Not above RS. xx" statement, I conceded and started to leave the bank. At this point, the bank employee left my blank signed cheque on top of her desk while she walked away for a cup of tea!

Sure, this might not be the most dangerous scenario since there are security cameras all around and the bank's employees have undergone background checks and are well trusted. However, Banks need to realize the security has as much to do with process audits and security cameras as it has to do with customer's psychology. It is important that as responsible organizations, we send the correct message to customers about what is acceptable and what is not in-terms of security. Banks need to realize that if you encourage customers to give blank signed cheques, you are telling them that it is acceptable practice.

It is processes like this one that let users believe that this sort of behavior is acceptable or safe. No wonder hotels and other organizations ask you to provide credit-card details over the phone/email, while the person on the other end writes them down.

This particular incident reminded me of another instance where I have seen something similar.

Another Bank where I have an account constantly sends me e-mails with new offers that have links like "offer_name.bank.com". I think it is a horrible idea to tell you users that it is OK to click links with "xyz.bank.com" as many phishing scams provide links like, "xyz.bank.malicious.com/bank.com" etc which might not look very different to a non-tech user.

Banks need to realize and carefully analyze the psychological impact of their processes on what their customers deem to be acceptable or not. Proper and well thought out processes and policies could in the long-term be the difference between whether a user clicks a malicious phishing link or reports it.

Airtel Injecting Ads into User's Browsers

Most businesses have one aim, maximize profits. However, while doing so there must be a balance between risk management, customer security and most importantly - FAIR-PLAY.

Indian ISP and mobile communications provider Airtel seems to have forgotten this exact rule. For almost a week now, Airtel has been "hi-jacking" user's HTTP requests and injecting them with full-page ads of their own DTH service (Screenshot).



To add even further security risk to this mess, I am fairly certain that the page used to display Advertisements is vulnerable to a Cross-Site Scripting attack. This means that an attacker can steal the cookies of an Airtel user even if the web-site in question has no obvious flaws.

Besides for the obvious risks faced by the XSS flaw, there is also the matter of how they handle:

• SSL connections.
• Client-side certificates.
• Sensitive user data sent via web-forms only to be interrupted by Airtel ads.
• Users carrying out Banking or other sensitive activities which when interrupted can result in multiple payments being processed.
• and most importantly, what guarantee is Airtel providing in-regards to user requests and information being maliciously redirected and stored on the Airtel ad-server.
  

Also, what about the fact that they are further affecting web-publishers advertising revenues by placing ads on content they did not write or develop. This is an extremely grim move on the part of Airtel and I sincerely hope that no-other ISPs continue in its footsteps.

Airtel may have made a few extra bucks from these ads, but I for one will never be using an Airtel service as far as I can help it.

Indian Information Security Incidents Gallery

I was recently on the phone with Dinesh O'Bareja and he mentioned a blog he started sometime back to document Indian Information Security Incidents. I think its a great initiative on his part and one that we definitely require in the Indian IT Security space.

As anyone who has been involved in the Indian IT industry can tell you, for most organizations security is always a low priority. One of the reasons for this is the lack of corporate liability for the loss of customer data.

Most companies that are faced with a breach use the hush-hush approach and sweep the incident under the rug. This causes consumers who have had their personal information compromised to be left in the dark until their next statement shows up with fraudulent transactions.

In other countries, there are Security Breach Notifications Laws in place to ensure that the consumer is well informed and the responsible company either compensates the victim or subscribes them to an identity monitoring service.

Coming back to the India InfoSec: Incidents Hall of Shame / Fame Gallery Blog, I think Dinesh has definitely taken the right step. Only when we have more attention given to Security Incidents will we see companies dealing with them in a more responsible/liable manner.

So if anyone out there has witnessed any security incidents, go ahead drop Dinesh an e-mail.

Budgeting for Web Application Security

Great post on Budgeting for Web Application Security by Jeremiah Grossman.

Some key approaches are:

1. Risk Mitigation - "If we spend $X on Y, we’ll reduce of risk of loss of $A by B%."
2. Due Diligence - "We must spend $X on Y because it’s an industry best-practice."
3. Incident Response - "We must spend $X on Y so that Z never happens again."
4. Regulatory Compliance - "We must spend $X on Y because PCI-DSS says so."
5. Competitive Advantage - "We must spend $X on Y to make the customer happy."

Police Backdoors

I ran across this article titled "Police set to step up hacking of home PCs" the other day. It details a new law approved by the UK government allowing police to hack into suspected home computers. In-order to carry out these Hacks, they will be sending E-mails with virus attachments or breaking into homes and installing keystroke loggers.


This kind of behavior is displayed by most governments these days. However, what did surprise me is that they asked security product/service providers to stop detecting/blocking their keystroke loggers and other malicious tools.

I was glad to read that a few security vendors have taken issue and denied cooperation with this matter. As per ZDNet, security vendors Kaspersky Labs and Sophos told ZDNet UK that they would not make any concession in their protective software for the police hack.

Symantec declined to comment on whether it would block a police hack, saying the matter was "politically sensitive". However, the security vendor has said in the past that it would not scan for the FBI's Magic Lantern keystroke-logging software.

I personally think the entire concept is ridiculous, especially the part where security vendors are expected to turn a blind eye to these police hacks. I feel that an AV that would voluntarily miss malicious code used for these police hacks would probably as a direct result miss other malicious code also.

Also, If any malicious users or malware authors were to get their hands on this malicious police code (which is fairly likely since they are installing it on suspect PCs), it would be fairly easy to reverse engineer the code and create malware to mimic its behavior and bypass security software.

Security through obfuscation, i.e. with the hope that no-one will look there, or look deep enough is always a bad idea. The entire concept of asking Vendors to create police backdoors sounds to me like a malformed version of "Security through obfuscation".