If you think your organization is free of botnet controlled hosts (aka zombies), it's only because you don't have the right detection tools! For example, Damballa, a botnet detection company claims that every organization it has tested was infected. And the number of infected hosts is rising – from 5% to 7% last year to 7% to 9% this year.
In one sense, this is a shocking number, i.e. almost 10% of the hosts in your network are controlled by botnets. On the other hand, not so much because I have yet to find an enterprise with hosts not running non-compliant or non-monitored software.
Another interesting finding from Damballa's research is the proliferation of small, customized botnets. Here is a quote from the Dark Reading article:
"The bad guys are also finding that deploying a
small botnet inside a targeted organization is a more efficient way of
stealing information than deploying a traditional exploit on a specific
machine. And [Damballa VP of Research Gunter] Ollmann says many of the smaller botnets appear to have
more knowledge of the targeted organization as well. "They are very
strongly associated with a lot of insider knowledge…and we see a lot
of hands-on command and control with these small botnets," he says.
There are several advanced security tools that can be easily deployed in a couple of days that will pinpoint non-compliant and non-monitored software and network communications.
The London-based Times OnLine had a story today entitled, "New Trojan virus poses online banking threat." With all due respect, Mike Harvey, their Technology Correspondent, appears to have gotten a few things wrong as follows:
The headline is referring to the Clampi Trojan, which is not new. It was first discovered in 2006 according to McAfee and 2008 according to Symantec. In fact as late as July 23rd, Symantec classified Clampi as "Very Low" risk. Since then, Symantec has raised the risk level to "High."
The Clampi Trojan is just one of many trojans that cyber criminals are using to steal people's online banking credentials. What these trojans have in common is the keylogging capability, i.e. the ability to capture all of your keyboard clicks.
The real story is that sophisticated cyber criminals are focusing on stealing money directly out of small and medium business accounts.
For more details on Clampi and funds transfer fraud, see my earlier blog posts here and here respectively.
Two more high profile organizations have succumbed to Web 2.0 based exploits, New York Times and RBS Worldpay. These highlight the shortcomings of traditional IT security. I have no doubt that both of these organizations had deployed traditional firewalls and other IT Security tools, yet they were still breached by well understood exploit methods for which there are are proven mitigation tools.
The current RBS Worldpay problem was merely a hacker showing off a SQL Injection vulnerability of RBS Worldpay's payment processing system. Late last year RBS Worldpay suffered a more damaging breach involving the "personal and financial account information of about 1.5 million
cardholders and other individuals, and the social security numbers
(SSNs) of 1.1 million people."
The New York Times website itself was not breached. A third party ad network vendor they use was serving "scareware" ads on New York Times site. Martin McKeay points out on his blog:
"it appears that the code wasn’t directly on a NYT server, rather it was
served up by one of the third-party services that provide ads for the
NYT. Once again, it shows that even if you trust a particular site
you’re visiting, the interaction between that site and the secondary
systems supporting it offer a great attack vector for the bad guys to
gain access through."
On the other hand, the average user coming to the New York Times site is not aware of this detail and will most deservedly hold the New York Times responsible. Web sites that use third party ad networks to make money, must take responsibility for exploits on these ad networks. For now, as usual, end users have to protect themselves.
I recommend that Firefox 3.5 users avail themselves of Adblock Plus and NoScript. Adblock Plus obviously blocks ads and NoScript by default prevents JavaScript from running.
What's particularly interesting about NoScript is that you can allow JavaScript associated with the site to run but not the JaveScript associated with third party sites like advertising networks. Based on my reading of Troy Davis's analysis of the exploit, if you were using Firefox 3.5 and running NoScript with only New York Times JavaScript allowed, you would not have seen the scareware ad.
The Apache.org team published the details of a recent incident where one of their web sites was breached. While the details are, of course, very technical, it provides a great learning experience for the rest of us. Dan Goodin of the Register summarized the incident.
Unfortunately, most organizations are very reluctant to even admit when they are hacked, let alone share the details of the experience. Hence the various federal and state laws forcing organizations to report incidents where people's personal and/or financial information may have been disclosed.
Given the fact that Apache produces open source software (the number one web server software), it is appropriate that they would be so open about a breach.
Computerworld reported last week that a judge in Illinois ruled that a couple who lost $26,500 when their bank account was breached can sue the bank for negligence for not implementing "state-of-the-art" security measures which would have prevented the breach.
While bank credit card issuers have been suing credit card processors and retailers regularly to recoup losses due to breaches, this is the first time that I am aware of that a judge has ruled that a customer can sue the bank for negligence.
The more detailed blog post by attorney David Johnson, upon which the Computerworld article is based, discusses some really interesting details of this case.
The plaintiffs sued Citizens Financial Bank for negligence because it had not implemented multifactor authentication. The timeline is important here. The Federal Financial Institutions Examination Council (FFIEC) issued multifactor authentication guidelines in 2005. By 2007, when the plaintiffs' breach occurred, the bank had still not implemented multifactor authentication. The judge, Rebecca Pallmeyer of the District Court of Northern Illinois, found this two year delay unacceptable.
Two interesting complications – (1) The account from which the money was stolen was from a home equity line of credit account, not a deposit or consumer asset account. (2) This credit account was linked to the plaintiffs' business checking account. I discussed the differences between consumer and business account liability here. Fortunately for the plaintiffs, the judge brushed these issues aside and focused on the lack of multifactor authentication.
One issue that was not addressed – where was Fiserv in all of this?
They are the provider of the online banking software used by Citizens
Financial Bank. Were they offering some type of multifactor
authentication? I would assume yes, although I have not been able to
confirm this.
In conclusion, attorney David Johnson makes clear that this ruling increases the risk to banks (and possibly other organizations responsible for protecting money and/or other assets of value) if they do not implement state-of-the-art security measures.
In the last week, vulnerabilities in older versions of WordPress software have been exploited resulting in blog posts being deleted and the blog sites being used for malicious purposes. Welcome to the real world.
The shock that some people are expressing, like Robert Scoble on Scobleizer is somewhat surprising. It's clear that WordPress knew about the vulnerabilities for some time and urged self-hosting customers to upgrade to WordPress version 2.8.4. Some of those that did not, have paid the price. Here is some additional useful information.
People have been snickering for years about Microsoft's security travails. We have since learned that Microsoft does not have a monopoly on security vulnerabilities and exploits. All software products have vulnerabilities. The issue is that as a software product becomes popular, it attracts cyber criminals. Therefore, software companies, as they become successful, must increase their focus on security issues, which WordPress seems to have done.
And we as consumers of software have risk management responsibilities too:
Upgrading to current releases
Backing up regularly to increase resiliency, i.e. the ability to recover quickly from an attack.
Controversy around the PCI DSS compliance program increased recently when Robert Carr, the CEO of Heartland Payment Systems, in an article in CSO Online, attacked his QSAs saying, "The audits done by our QSAs (Qualified Security Assessors) were of no value whatsoever. To the extent that they were telling us we were secure beforehand, that we were PCI compliant, was a major problem."
Mike Rothman, Senior VP of eIQNetworks responded to Mr. Carr's comments not so much to defend PCI but to place PCI in perspective, i.e. compliance does not equal security. I discussed this myself in my post about the 8 Dirty Secrets of IT Security, specifically in my comments on Dirty Secret #6 – Compliance Threatens Security.
Eric Ogren, a security industry analyst, continued the attack on PCI in his article in SearchSecurity last week where he said, "The federal indictment this week of three men for their roles in the
largest data security breach in U.S. history also serves as an
indictment of sorts against the fraud conducted by PCI – placing the
burden of security costs onto retailers and card processors when what
is really needed is the payment card industry investing in a secure
business process."
The federal indictment to which Eric Ogren referred was that of Albert Gonzalez and others for the breaches at Heartland Payment Services, 7-Eleven, Hannaford, and two national retailers referred to as Company A and Company B. Actually this is the second federal indictment of Albert Gonzalez that I am aware of. The first, filed in Massachusetts in August 2008, was for the breaches at BJ's Wholesale Club, DSW, OfficeMax, Boston Market, Barnes & Noble, Sport Authority, and TJX.
Bob Russo, the general manager of the PCI Security Standards Council disagreed with Eric Ogren's characterizations of PCI, saying that retailers and credit card processors must take responsibility for protecting cardholder information.
Rich Mogull, CEO and Analyst at Securosis, responded to Bob Russo's article with recommendations to improve the PCI compliance program which he characterized as an "overall positive development for the state of security." He went on to say, "In other words, as much as PCI is painful, flawed, and ineffective, it
has also done more to improve security than any other regulation or
industry initiative in the past 10 years. Yes, it's sometimes a
distraction; and the checklist mentality reduces security in some environments, but overall I see it as a net positive."
Rich Mogull seems to agree with Eric Ogren that the credit card companies have the responsibility and the power to improve the technical foundations of credit card transactions. In addition, he calls the PCI Council to task for such issues as:
incomplete and/or weak compliance requirements
QSA shopping
the conflict of interest they created by allowing QSA's to perform audits and then sell security services based on the findings of the audits.
Clearly organizations have no choice but to comply with mandatory regulations. But the compliance process must be part of an overall risk management process. In other words, the compliance process is not equal to the risk management process but a component of it.
Finally, and most importantly, the enterprise risk management process must be more agile and responsive to new security threats than a bureaucratic regulatory body can be. For example, it may be some time before the PCI standards are updated to specify that firewalls must be able to work at the application level so all the the Web 2.0 applications traversing the enterprise network can be controlled. This is an important issue today as this has been a major vector for compromising systems that are then used for funds transfer fraud.
The Washington Post reported yesterday that there is an increase in "funds transfer fraud" being perpetrated by organized crime groups from Eastern Europe against small and medium U.S. businesses.
It's hard to know the extent of this type of crime because there is no breach notification requirement since no customer information is disclosed. However, many companies are reporting these crimes to the FBI and of course to their banks.
The risk of funds transfer fraud to businesses is much higher than to consumers for the following reasons:
Dollar amounts are higher.
Under the Uniform Commercial Code, businesses only have two days to dispute charges they feel are unauthorized. Consumers have 60 days from the time they receive their statements.
Because banks are liable for the consumer losses and less so for the business losses, they invest more resources in protecting consumers.
The complete article in the Washington Post is well worth reading.
In a previous post, I highlighted one of the techniques used by cyber criminals where they surreptitiously install the Clampi trojan on a PC in order to get the login credentials needed for online banking.
Recommended actions:
Install anti-virus/anti-malware agents on all workstations and keep them up-to-date
Use an end-point configuration management system to discover all workstations, to assure the above mentioned agents are installed and up-to-date, and to assure that unauthorized software is not installed
Implement firewall policies to (1) assure that only authorized people (i.e. people in authorized roles) using only authorized workstations can connect to financial institutions to perform funds transfer transactions, (2) assure that people not authorized cannot connect to financial institutions, (3) generate alerts when there are attempts to violate these policies
Implement a process where funds transfer transactions are reviewed on a daily basis by someone other than the person or people who perform the transactions
The Department of Health and Human Services this week published the regulations for the "breach notification" provision of the Health Information Technology for Economic and Clinical Health (HITECH) Act, of the American Recovery and Reinvestment Act of 2009 (ARRA). In effect, this is an extension of HIPAA and further strengthens HIPAA's Privacy Rule and Security Rule.
The new breach notification regulations are in a 121 page document. HHS also issued a press release that summarizes the new regulations.
This type of breach notification regulation started in California with SB 1386 which went into effect on July 1, 2003. Since then about 40 other states passed a similar law.
In 2008, California went on to pass a specific health care information protection law, SB 541, which requires notification of breaches and financial penalties up to $250,000 per incident. Here is a Los Angeles law firm's presentation on it. Since SB 541 went into effect on January 1, 2009, there have been over 800 incidents reported.
The recent Goldman Sachs breach of proprietary trading software highlights the risk of insider fraud and abuse. RGE, Nouriel Roubini's website, has the best analysis I've read on the implications of such an incident.
Here is the money quote, "What is troubling about the Goldman leak is how unprepared our infrastructure is against active measures. We already have good security practices, defamation laws and laws against market manipulation. What we don't have is a mechanism for dealing with threats that appear to be minor, but where the resulting disinformation is catastrophic."
I cannot imagine any better proof of the need for better user, application, content, and transaction monitoring and control tools.
