Wednesday, May 09, 2012

Detecting DNS Changer Infection with CloudFlare and OpenDNS

If you're using CloudFlare to enhance speed and security (it's a great, free service, by the way!), you'll want to check out one of their latest apps, created in conjunction with OpenDNS. The app will notify your website visitors if they are infected with the DNS Changer malware.

If you're not familiar with the DNS Changer malware, it modifies settings of the victim computers, rerouting traffic to banks and other sites of interests through the hands of the bot masters. This means sensitive information could be compromised.

Last year the FBI was able to legally take over the DNS Changer rerouting systems, protecting the victims to some degree. However, the FBI has to relinquish control in July, meaning victim systems which have not been fixed will be unable to access websites as normal. The FBI has an in-depth writeup on the DNS Changer malware (PDF link), along with information on how to find out if you're infected and how to fix the problem.

Enter the CloudFlare application. If you enable this application, CloudFlare will notify DNS Changer infected visitors to your website that are compromised. They also provide a link with instructions on how to fix the problem. Here's what the notification looks like:

Friday, May 04, 2012

Firewalls and Anti-Virus Aren't Dead - Should They Be?

Over the last several years, firewalls and anti-virus have been losing effectiveness. Many in the information security community have recognized this. Unfortunately many of the business and operations people haven't. The threats that these technologies (tools to assist in a solution, not the solution themselves) were designed to solve have changed. That's not to say that they do nothing - they can still be useful - but your organization needs to know what they're meant to counter and how to use them properly.

I was inspired to finally write this down by a story Wendy Nather contributed to Infosec Island, entitled Why We Still Need Firewalls and AV. While I agree with her general premise, I think the article doesn't get to the real heart of the issue. When firewalls and anti-virus were all we had and effectively countered the threats we faced, they tended to be used more as they were designed. But now, firewalls and anti-virus don't counter the majority of the threats and aren't used very well.

Firewalls were invented a couple of decades ago to keep Internet-borne threats out. The firewall has its roots in the early 1990s, a time when commerce was prohibited on the Internet and most companies didn't have any presence there. As computer networking grew in popularity, connecting to the Internet was a way to share information across organizations, as well as internally. However, within a decade, Internet attacks were prevalent and organizations needed a way to protect the devices on their network. The firewall was popularized as a way to enforce a hard separation between the outside and the inside. The major advantage to this approach was that it was much cheaper than securing every single device. And at the time just as effective, since most devices had no need to communicate over the Internet and so a small set of connections were allowed to pass through the firewall.

The Internet landscape has changed drastically since then. And with it, the Internet threats. Modern business processes are highly dependent upon and thoroughly integrated with the Internet. Organizations invite masses of Internet devices into their network to deliver web pages, email content, support mobile devices and dozens of other reasons. At the same time, devices within the network routinely initiate communications to the Internet and pass data back and forth. Firewalls have gotten better, but they simply can't handle the new ways in which organizations work on the Internet, nor the more sophisticated threats. They still have a use as a tool to protect networks, but more tools are needed.

Similarly, anti-virus was first developed to detect, prevent and remove individual viruses. These software packages were simplistic, identifying malicious programs and files by looking for indicators or "signatures" that were unique to each virus. This was, again, before the Internet was widely used and most virus transmission was very slow. The anti-virus industry was easily able to keep up with new viruses and forms of existing viruses. This was a time when the number of specimens was very small and they didn't change very often. Updating the signatures was a task done once a year or so, and in fact when the subscription-based licensing model for anti-virus was initially launched it was widely viewed as somewhat of a betrayal of trust - paying continually for the same software. It was a different time.

But today's situation is vastly different from what anti-virus was designed to deal with. Because of the proliferation of Internet connectivity, malicious software spreads very quickly. Instead of taking months to spread to thousands of systems, it takes seconds to spread to millions. And the malware itself has become much better at avoiding detection, taking steps to hide its signature. Most viruses today are obfuscated a number of times and checked to make sure no anti-virus software can detect it - all in a matter of seconds, and all before it's sent out to its victim. And viruses are often created and distributed in such a way that anti-virus vendors don't get a copy before the malicious software finds its victim. And when it does infect a device, it frequently disables any anti-virus software and hides in such a way that it can't be detected except by sophisticated, usually manual techniques. Anti-virus software largely still relies on signature based detection, which is increasingly growing ineffective and often slows down system performance.

Further decreasing the effectiveness of firewalls and anti-virus in organizations is the way they're used. Because of the massive number of connections in and out of a network, definitions of what is and is not allowed and exactly how to allow or deny network connections have become a sprawling mess. And underneath all this complexity, many organizations don't even do the basics right - properly configuring and managing these tools. And administering anti-virus often means running daily reports of issues and sending a technician onsite to manually investigate what's gone wrong. Firewalls and anti-virus cost many organizations millions of dollars a year and are failing to do what they should.

So why should we keep these things around? In the case of firewalls, they do exactly what they are supposed to do and do it quite well. Organizations just need to get smarter about using them. That means limiting firewalls' purpose to what they do well and handing off other duties to other tools. In addition, organizations need to make sure they have a good firewall management program - even small organizations. And anti-virus should be re-understood as a broader concept of endpoint protection. This includes securing configurations and access, restricting software to that which is known to be safe and putting tools in place to detect anomalous behavior. Anti-virus software packages can help fulfill the last piece - telling systems administrators that a known threat has been detected or that suspicious activity has been happening.

But one thing I think we as security professionals should be advocating is reducing the amount of money and resources spent on these technologies. Instead, shift to more effective ways to secure an organization. For example, by providing better training to IT staff for using with the existing tools and technologies. Or improving security awareness programs so that viruses (not to mention many other types of attacks) are less likely to be effective. In the end, this will allow an organization to maintain the same level of security at a lower cost or to increase security at the same cost.

Wednesday, May 02, 2012

What Infosec Can Learn from Enron

Enron's financial auditors and management conspired against their investors. The system that was supposed to protect against this kind of fraud, instead worked against the people it was supposed to protect. And there was hell to pay when the organizations collapsed and when the fraud was exposed. The Harvard Business Review today makes the point that just because an auditor approves something, that doesn't always mean its right.

Information security professionals, take a lesson from Enron: auditors aren't the sole authoritative voice, and they can be fooled or coerced just like anyone else. Too often internal and external auditors are trusted as the arbiters of what's right and wrong. But this can fail an organization if the executives don't understand what role the auditors should be playing.

Auditors serve as an important check on the system by assessing against a known framework. But there is always room for interpretation in any standard. That's especially true in areas where standards are evolving quickly or where a new field is opening up. That was the case for Enron with the "mark to market" strategy, and that is true today in Infosec.

How do auditors fail the organizations they serve?
Let's use the Payment Card Industry Data Security Standard (PCI-DSS) as an example. The PCI-DSS has done a lot of good over the years it has been around. But as IT, payment systems and threats have changed, it has had a hard time keeping up. As an instructor famously said in a class I attended, the DSS only changes once every two years; but the Security Standards Council (SSC) can change the meaning of the words they use at any time.

The PCI-DSS has also heavily misinterpreted. The standard is meant to be flexible so organizations can find the right security controls, rather than blindly following what's written. However, many auditors stick staunchly to the standard, verbatim. That means the company either has to jump through hoops to get their official compliance stamp, or can game the system to fit within the narrow definitions. Other auditors are so easily influenced or coerced by their client that virtually any control is deemed adequate.

And there's room for abuse of the standards, as well. Some audit companies are well-known for providing "clean" or "green" reports to their clients (sometimes those who spend above a certain dollar level), regardless of what the actual security looks like. Breaches have left several organizations wondering why they paid high fees to auditors who didn't find the security flaws.

So it's important to know how much to trust your auditors and what role they serve. You can't give them authority to make your decisions for you, but you can use them as advisers. In the Enron case, their auditors had huge amounts of business in other areas, meaning there was a conflict. In your organization the auditor may be trying to get a big contract, unseat a competitor, make a name for himself or whatever. In these cases the bad advice is almost always unintentional, but still present.

Probably once every month or two I speak with a high-level executive looking to hire someone to check behind their auditor. It's usually because the executive suspects of one of the failures above. In reviewing the work done by the auditor I usually find that the executive's instinct is right.

How can you help your audit succeed?
Choose your auditors carefully and use the right process. I helped write the SANS whitepaper How to Choose a Qualified Security Assessor (PDF link) and there's other good questions to ask for choosing an auditor elsewhere. But it goes beyond just choosing the right auditor, you have to have the right audit process in place. Here are some tips to avoid the pitfalls that got Enron into trouble.
  • Evaluate Reputation. Not just whether they've done a lot of audits before, or whether all their clients pass, but whether they are perceived to have high integrity, technical capabilities and security knowledge. Don't get this from the auditor or their hand-picked references, ask around. Reputations follow companies and people and are spread quickly.
  • Evaluate Skillset. Auditors falling too far toward leniency or rigidity often do so because they are not well-versed in IT and security. That means they don't understand the intent of the standards they're auditing against, which means they can't possible give you good advice that's outside of the letter of the standard.
  • Oversight. Make sure there is good oversight of the auditors that are performing the work. This could be done by an internal audit group, a CISO or even a CIO. The point is that someone needs to make sure the work is not just done, but done right - thorough, accurate and independent.
  • Use Auditors as Checks. Don't forget that auditors should be checks on what you're doing, they shouldn't be telling you exactly how to do it. They've often got a lot of good advice, but you have to weigh that advice carefully within the context of your business and your ethics.
But even going through a thorough diligence process can get you stuck with a bad auditor. That happens. But when it does, you've always got the option to get a second opinion. And I'll leave you with a great video on some signs you've got a bad auditor.

Saturday, April 28, 2012

What Biosecurity Can Learn From Infosec

Introduction
Recently there has been been debate over research on the H1N1 strain of influenza. This is the strain sometimes called avian flu or bird flu. Many researchers have been studying all they can about the disease, while many researchers, institutes and governments are trying to prevent more research. The arguments on both sides are complex and nuanced, and each side has many valid points.

While I don't want to recap the entire argument, I'll try to summarize each position in a sentence or two. The pro- side believes that legitimate research will help us deal with any eventual version of the virus that can spread from human-to-human. The con- side belives that research makes it more likely that a very deadly strain might make its way out of the lab, or that terrorists or governments will be able to more quickly have a weaponized strain.

Current Situation
While public science on H1N1 may cease, the virus itself will keep evolving. Life will always experiment with new forms. Eventually one of these may be a variant of H1N1 that is successful in spreading human-to-human. That is, it finds a new evolutionary niche it can exploit.

And certainly it's to be expected that organizations currently researching biotechnology for warfare would continue. What we saw with chemical weapons in the first World War was private research done by corporations being co-opted for use by the military. Bioweapons research groups may even reduce or discontinue their work in the presence of public research, because any effective weapon is likely to be much less effective if it is well understood and can be effectively combated.

Comparison to Infosec
There has always been a lot of research on finding security vulnerabilities in software. Some researchers look for vulnerabilities so issues can be fixed. Some researchers look for vulnerabilities so they can break into systems. And so in the Infosec community we used to have similar discussions as those going on in the Biotechnology and Biosecurity community now. 

That debate always used to remind me of a bad movie chase scene. When the person fleeing sees a big rock coming up quickly, he stays calm and turns at just the right angle - a near miss. When the person chasing sees it he panics and throws his arms in front of his face - a gratuitous explosion ensues.

Fortunately in the Infosec industry we have mostly moved toward the first course - staying calm and taking just the right angle. But for a while we, too, had lots of people who tried to make the rock go away by hiding from it. Many times this was software developers who reacted more violently to the legitimate research than to the criminal research! And the software developers have benefited by having much more robust and secure products.

Benefits of research and publication
Research helps in that:
  • identifies potential issues before they are found in the wild
  • allows us to prepare for likely strains before we see them
  • able to refine methods of doing this kind of research
  • gives us a better idea of the actual threat level - more or less severe than imagined
  • shows us indicators of what an outbreak might look like
  • shows us indicators of what an attacker might need to create a bioweapon
Publication helps in that:
  • publicizes the fact that these risks exist and are being studied
  • attracts more scientists
  • attracts more funding
  • allows results to be peer reviewed
  • identifies those working in the field to facilitate collaboration
Alleviating fears
One fear is that the research may be co-opted by a nation state for biowarfare. But I would argue that the antidote for that is more research, not less. The same fear exists in Infosec and that's just the way we've tried to deal with it. Hundreds of people doing security research, banging away on software. They're not going to find all of the bugs, but they're likely to find quite a few of them. Looking at it from the other direction, if governments quash open, public research, the only people who will be looking for a bug will be the ones looking for a weapon. And of course you can't legislate nature not to find a virulent strain.

But like in the Infosec community, there is still a question of the right amount of disclosure. Some in both fields advocate a full disclosure stance. That is, every detail should be published as soon as it is known. Others advocate a more limited disclosure policy, only publicly releasing enough information to describe the issue and to protect against it. Releasing certain technical details only to those who will be a part of the solution to the problem.

Publishing technical details is important for a couple of reasons. First, it ensures that the results can be replicated. This part of the scientific process is critical to the reliability of the results, as well as to identify potentially significant but unknown variables or mistakes. Second it provides foundations upon which future scientists can improve their techniques. Process and methodological innovation are critical to the scientific process, especially in this case where nature and bioterrorists are continually improving their results.

In many minds, the biggest fear is that we do nothing. If nature or a bioweapons group creates a viable threat, our lack of preparation will doom us to a greater impact. But if we understand the H1N1 virus well then we will either have defenses in place or can quickly take action. And as previously mentioned, public research may discourage groups from trying to develop weaponized versions in the first place.

Summary
Biotechnology should be looking (particularly in the case of Avian H5N1 Influenza) to increase scientific study and publication, rather than suppress it. The more scientists who work on it and publish their results, the more likely we are to find a way to defeat both a natural and unnatural strain of the disease. But certain technical details should be limited to a smaller group who rigorously review those details to make sure legitimate researchers stay ahead of the alternatives.

Articles
http://www.virology.ws/2012/01/03/should-we-fear-avian-h5n1-influenza/
http://www.economist.com/node/21553448
http://arstechnica.com/science/news/2012/02/maybe-avian-flu-isnt-that-deadly.ars
http://arstechnica.com/science/news/2012/02/study-of-deadly-flu-sparks-debate-amidst-fears-of-new-pandemic.ars

Update 2012-05-07: Since I published this article, I've had some discussions and there have been some new developments.
  • First, the paper in question has been published. Second, Nature has written a good article explaining the circumstances around publishing the controversial article
  • Second, I want to make clear that what I'm advocating is for Biosecurity to review our discussions and debate and apply it to their own situation. In other words, learn from our mistakes, successes and thought processes to speed up and improve their own.
  • Third, I've replaced "Biotechnology" with "Biosecurity" where it seems appropriate, in order to clarify to whom I am referring. I know Biotech spends billions and has well developed processes in place for research. Infosec ourselves can probably learn from their process.

Friday, April 20, 2012

Cybercrime Does(n't) Pay?

Earlier in the week a couple of Microsoft researchers released a study of cybercrime financial loss statistics (Sex, Lies and Cybercrime Surveys - PDF link). Effectively their research indicated that bad sampling, survey and statistical methods have led to a number of dubious results. I think most of us who are involved in the industry have known this intuitively for a while. Any time you have metrics purportedly for the same thing that vary by factors of 10-1000, that says something isn't quite right. 
 
The conclusion of the paper is essentially that estimates of the cybercrime economy are grossly exaggerated. And they make the point well enough that I won't belabor it here. Go read the actual article (linked above). I'm more interested in how this applies to other areas and studies. Here are a couple of points I think are particularly relevant, as well as a couple of others.
  1. Heavy Tails. Means (averages) are most useful when all the data are clustered closely around that number. When the distribution is very wide, you're going to have a problem getting people to understand what the results mean. For example, if I said that the average cost of a DVD player is $100 it doesn't tell you anything meaningful about the market for DVD players. That's because the costs range broadly, so the mean is almost arbitrarily in the middle somewhere.
  2. Garbage In, Garbage Out (GIGO). Since the data in these studies is typically collected by sending surveys, it's impossible to verify its integrity. In some cases people outright lie, but in others they simply don't know true costs and are just guessing. They may be higher or lower than the actual, but since there are never negative values, the overall trend almost necessarily has to push the number higher than the true value. But by how much it's impossible to know.
  3. Attribution. It's not easy to know where fraud came from. How do you know that somebody stole your credit card number from an online database, versus going through your trash or copying it at the restaurant down the street? This kind of attribution is especially hard for consumers who often can only know about an incident after actual fraud or if they are issued a new credit card. If both things happen within a year or so, the consumer is likely to think one caused the other, though as we know correlation does not imply causation.
  4. Self-Selecting Population. The people who respond have at least one thing in common - they return surveys. They may have other things in common, like a tendency to overestimate numbers, to be particularly susceptible to cybercrime, or any number of dozens of things that could influence the validity of these studies.
This isn't just a problem that affects cybercrime statistics, though. The Ponemon institute annually puts out a similar report on losses due to breaches (as well as a report on cybercrime). Their methodology is similar to the ones discussed in the Microsoft paper, and therefore suffers from some of the same flaws. To get consistent results over time that show a trend consistent with expectation, I suspect that some data manipulation goes on, which would add yet another layer of bad science (if true - I only have my gut instinct to go on, not any facts).
 
One group that tries obsessively to get the science right is Verizon Business who puts out an annual breach report. This uses much better science and statistics and can be counted on to have some rigor. Results can vary wildly year-over-year because they are always introducing new data populations (several groups contribute their figures, most with a different demographic that they serve), but that will normalize somewhat in the next 5 years as their data set gets big enough that new populations skew it less. The raw data is collected and published openly so there can be some good peer review of it, an important step for ensuring validity of results and conclusions.

But these studies don't have to be done poorly. By changing the way the researchers go about it, they could get much better results. For example, if instead of going to consumers with a survey, the authors had been able to get the information from banks the numbers would have likely been very different. The banks would have objective measurements of customer losses, a properly large sample size, a randomly distributed population, and would likely know more about the source of the fraud.

Although many of these studies fail at basic science, I'm hopeful that the information security industry will get better. Both at true academic research and at coming up with accurate public metrics for many of the most important data. We'll get there as we mature as an industry, but it will take a while. Until then, stay skeptical.