Is this good? Is this scary? Do you want your bank "doing a NAC thing" on your PC before allowing you access? "Banks are seeking access to customer PCs used for online banking transactions to verify whether they have enough security protection."
After I thought about it for a while, I decided that it IS a good thing, UNLESS their policy will now say that "customer is liable for all web transactions" [including those done by malware not detected by the bank security check...].
If that will indeed be the case (the article doesn't say it though), it will be be time to change banks "because of security." :-)
8 comments:
This is a very hot subject here in Brazil, where malware targeting banks customers is very advanced (key logging, screen capturing, dns poisoning and lots of other "features").
Here banks usually have the liability over the frauds, so they are pushing a lot of controls over the customer. Some of them are including ActiveX controls (G-Buster) to check for the most common malware. If they make it clear that they're installing software on your computer and that it's a basic condition for taking the liability over fraud, it's ok.
Well, if they still have liability over fraud, than it is indeed OK...
It's not a good thing if the banks block customers because of false positives.
It's not a good thing if the bank poorly codes the scanners/checkers so that they themselves contains vulnerabilities or weaknesses in their application implementation. This is my biggest problem with NAC.
To be honest, I think it's a waste of time. Banks should spend more time fixing the vulnerabilities present in their websites, signing all the code that is executed on the client, and implementing user protections such as HTTPOnly / content-restrictions where appropriate.
Actually, even better would be if banks didn't shoot the messenger when a vulnerability is reported to them, or comes to their attention. You can tell the level of maturity, and probably the level of information assurance - of any given organization just by watching how they respond to incidents outside of their organization that present a new vulnerability in the wild (or even via a responsible disclosure). Almost all fail.
Yea, totally! At the same time, I am guessing they face more loss via trojaned boxes doing transactions on user's behalf compared to direct data theft from a bank; thus focus on client security.
BTW, does this mean signing all the WEB code? How can a bank excercise control over any code running on the client (other than the security check mentioned in the article...)?
>signing all the code that is
>executed on the client,
BTW, does this mean signing all the WEB code? How can a bank excercise control over any code running on the client (other than the security check mentioned in the article...)?
Well with Java, there is jarsigner.
With Javascript, signing code is only available via Firefox. So banks should encourage Microsoft to add this feature.
I highly suggest you read the comments by Tim Brown in this blog article about XSS worm mitigation controls. His post is not only excellent, but the linked paper that he wrote in a previous year, as well as the direct link to signing Javascript code for Mozilla products is very on-topic.
Right now, even Firefox only allows signed-code to cross the same-origin policy (which is not a restriction, but an additional permission). But this could be extended to a "don't execute" policy with a few modifications to the browser.
Content-restrictions (such as HTTPOnly, but HTTPOnly has problems in both design and implementation as well as the fact that is it limiting) are probably the best way to start out with. It provides a way of having a trust path of execution (see Orange book stuff) for browsers. The next logical steps after having trusted paths is to have trusted code (signed code) and a trusted environment (integrity monitoring systems).
Thanks for the paper refs (going there right now)
Signed browser code stuff worries me a bit (even though it will be better than now). Wasn't there a case when some random folks got a cert to sign MS code?
Still, trusted path from bank to consumer thru browser sounds like a good idea.
Signed browser code stuff worries me a bit (even though it will be better than now). Wasn't there a case when some random folks got a cert to sign MS code?
Yes, you wrote about it in your book, Security Warrior in section 14.6, "Hacking PKI".
LOL. This irony is thick, check out that Bejtlich also forgot about what he wrote recently:
"Oh... so Omni implemented remote capture, which I blogged about in 2003 as implemented on Winpcap, and only works on Windows. Oh well.
Richard, you may have forgot that you wrote about http://rpcap.sourceforge.net in the last chapter of your book, TToNSM:BID."
LOL, that WAS funny indeed. Does it mean I write too much (and talk too much)? Probably - I hereby commit to spend 10% less time writing and 10% more time doing :-)
Post a Comment