<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 16, 2015 at 10:15 AM, Jim Gettys <span dir="ltr"><<a href="mailto:jg@freedesktop.org" target="_blank">jg@freedesktop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sun, Feb 15, 2015 at 9:45 AM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><a href="http://mobile.nytimes.com/2015/02/15/world/bank-hackers-steal-millions-via-malware.html?_r=0" target="_blank">http://mobile.nytimes.com/<u></u>2015/02/15/world/bank-hackers-<u></u>steal-millions-via-malware.<u></u>html?_r=0</a><br>
<br>
"In many ways, this hack began like any other. The cybercriminals sent their victims infected emails — a news clip or message that appeared to come from a colleague — as bait. When the bank employees clicked on the email, they inadvertently downloaded malicious code. That allowed the hackers to crawl across a bank’s network until they found employees who administered the cash transfer systems or remotely connected A.T.M.s. "<br>
<br>
<br></blockquote><div><br></div></span><div><div style="font-size:small;display:inline">​</div>I have to wonder whether the scale of banking losses going on due to home router DNS attacks may be much larger than <div style="font-size:small;display:inline">​directly ​</div>breaking into the banks<div style="font-size:small;display:inline">​ in that article​</div>, but since they are much more distributed, harder to detect.</div><div><br></div><div>See:</div><div><a href="http://securelist.com/blog/research/57776/the-tale-of-one-thousand-and-one-dsl-modems/" target="_blank">http://securelist.com/blog/research/57776/the-tale-of-one-thousand-and-one-dsl-modems/</a><br></div><div><br></div><div>Lest you think: "It's Brazil, and DSL, and doesn't apply to me", there are reports of similar attacks on cable routers in the U.S. We just don't know the scale (yet).  We do know the scale was 4.5 million routers just in Brazil 2-3 years ago...</div></div></div></div></blockquote><div><br></div><div>Banks don't worry about fraud losses, they worry about the cost of fraud. And $300 million is about the cost of 1,500 loaded staff. So proposals that would require ten banks to spend 150 person years effort are not going to interest them.</div><div><br></div><div>They are remarkably impervious to the argument that their fraud costs can rise very quickly.</div><div><br></div><div>I remember when the rogue trader in France cost their bank a billion dollars. Turned out that their compliance apparatus consisted of Excel spreadsheets maintained manually. </div><div><br></div><div> </div></div>What we could do to start with a fix is to recognize the need for malware type filtering on all network connections and build in a standard socket to the stack for that purpose. So if anyone is going to http:://<a href="http://alwaysmalware.com/">alwaysmalware.com/</a> they get a message back saying, 'oh no you are not'.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Google and Microsoft etc. all have these safe surf programs but they can only say 'we don't advise that' because their relationship with the user is that the user is their customer and they can't tell the customer what to do. Anti Virus vendors can tell the user what to do because that is what they pay us for. </div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I made a proposal 'Omnibroker' that would provide a standards based socket that every application can plug into when opening up a network client connection. I think that is a part of the solution.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Another part though would be to change the way applications are installed. The default should be that an application runs in a separate partition and does not see the shared file system or the general network. Least privilege is your friend.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Unfortunately, as with many much needed developments, the response is always 'users will never understand'. I think they underestimate the users who have no difficulty using well designed tools. The problem comes when the tools are botched. </div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">It takes about 45 minutes to configure S/MIME in Outlook as supplied by Microsoft. I have a tool that has no user interaction at all that does the same in 5 seconds. If you want an external CA issued cert you may have to give one extra piece of info - the DNS name of the CA. But even that can be done away with.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The thing is that ALL of the actions required to administer certs in S/MIME applications are unnecessary makework. But the failure to use encryption is put down to the user when it is actually the fault of Microsoft management for not telling their programmers that they have to do better. </div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">What we need is a Steve Jobs who cares about security. It is quite possible to implement secure systems that have Apple quality look and feel.</div><div class="gmail_extra"><br></div></div>