Category: General
Why Click Fraud Matters
Spending on Internet advertising in the US alone eclipsed $10 billion in 2010. Unfortunately, online sponsored advertising has a major downside: Click Fraud. Industry rivals, or other interested parties impersonate consumers by clicking on paid ads with no intent of making a purchase. These fraudulent clicks effectively drive up a company’s advertising costs without increasing sales. Click Fraud has become such a widespread issue that in the eyes of LinkShare CEO Stephen Messer, it “could wipe out ROI in search marketing.”
Initially, advertisers placed their trust in search companies such as Google, Yahoo and Microsoft to police fraudulent clicks. In 2006, Google CEO Eric Schmidt compromised that trust when he stated:
“Eventually the price that the advertiser is willing to pay for the conversion will decline because the advertiser will realize that these are bad clicks. In other words, the value of the ad declines. So, over some amount of time, the system is, in fact, self-correcting. In fact, there is a perfect economic solution, which is to let it happen.”
His statement led many companies to question the commitment of their providers to preventing Click Fraud.
At the heart of Click Fraud is the act of simulating a click. This is accomplished through multiple means. The simplest is to employ individuals who spend their time clicking on ads without ever purchasing an item. This act is both costly and time consuming if done inside the United States. In developing countries, this is not the case. In the words of Nir Kshetri, the fraudster “must often decide to employ the seemingly bottomless source of human clickers in developing countries, or use technology.” Kshetri goes on to point out that employing human labor becomes less attractive as PPC providers and advertisers become more adept at employing invalid click detection. Because the IP address of a human clicker is usually consistent, PPC providers can easily block traffic from it.
Another method for performing fraud is to write a program that simulates clicks. To do this, the program must perform many tasks normally undertaken by a web browser. The program must first execute JavaScript code to retrieve the HTML code of a web advertisement. It then parses the HTML code for links and sends an HTTP request to the advertiser’s web server. Since this type of fraud is simple to detect, the perpetrator must distribute the program across the Internet using a botnet. The botnets find their way onto unsuspecting users’ computers through many means. Tempting offers of free software, games or other goods from illegitimate websites lure many consumers into loading botnets unknowingly. Computers can also be infected by visiting legitimate websites that have been compromised by Click Fraudsters.
Unlike many other online crimes, Click Fraud has no offline counterpart. One impact of Click Fraud is that the legal system has not been able to keep pace with it. Online crime is growing at a rapid rate that legislators have been unable to match. Adding to the problem is a lack of regulation across borders. While new antifraud laws are slowly being passed in the United States and the European Union, other countries have little or no regulation. In India in 2006; for example, advertisements looking to hire people to click on ads ran in national newspapers.
As an industry, online advertising is not going away anytime soon. Click Fraud will not be going away either. Given my background in law, it is obvious to me that just like with other legal issues regarding technology, legislators cannot keep up with the rapid pace with which Click Fraudsters change their tactics. Add in the challenges of enforcing laws across international borders and the problem becomes even direr. It is therefore obvious that legal changes will not come soon, so other methods are necessary. With legal recourses lagging behind, it is up to industry to find ways to protect itself.
Twitter: To log or not to log: Is that the question?
As Twitter continues to thrive as the communications tool of choice amongst activists, dissenters and occupiers worldwide it should be no surprise that the San Francisco-based company is drawing heightened attention from US law enforcement agencies. Most recently, and likely to the surprise of even the most conspiratorial privacy advocates has been the Boston Police Department’s subpoena for data on a hashtag, #bostonPD. Yes, a supeona on a hashtag.
While Twitter has fought back against law enforcement agencies’ attempts to get their hands on user data in the past, it seems to be losing more than its winning. Twitter’s defiance towards LEAs has been its policy to notify users when their accounts have been subpoenaed, a policy that LEAs have sought to bypass.
This attention from LEAs has lead WikiLeaks to recommend a seemingly elegant solution: 
With the support of WikiLeaks the #NOLOGS hashtag is catching on quickly. No surprise there. as from an activist’s perspective this seems like a winning move against the ever-growing Big Brother state. The question that needs to be asked though is, would this actually provide the protection that activists are looking for and need? Also, probably more importantly, what kind of effect would a switch to a #NOLOGS policy have on Twitter’s 140 character worldwide conversation?
First let’s look at Twitter’s Privacy Policy to see what they Log:
Log Data: Our servers automatically record information (“Log Data”) created by your use of the Services. Log Data may include information such as your IP address, browser type, the referring domain, pages visited, your mobile carrier, device and application IDs, and search terms. Other actions, such as interactions with our website, applications and advertisements, may also be included in Log Data. If we haven’t already deleted the Log Data earlier, we will either delete it or remove any common account identifiers, such as your username, full IP address, or email address, after 18 months.
And what that data is used for:
Law and Harm: We may preserve or disclose your information if we believe that it is reasonably necessary to comply with a law, regulation or legal request; to protect the safety of any person; to address fraud, security or technical issues; or to protect Twitter’s rights or property.
From a logging perspective it’s important to consider the amount of data we are talking about here. Twitter claims to have 175 Million users, a statistic that some debate. However, from a logging perspective it matters not if the account is fake or real, they are still getting logged. Regardless of how this data is compressed and stored, this is a LOT of data, every single day. While the average tweet is only 140 characters, when you count the included metadata (IP, Location, Date, Time, browser type, the referring domain, pages visited, your mobile carrier, device and application IDs, and search terms) we are talking about a massive amount of log data. From a management perspective this is a lot of work. Storing and accessing that volume of data is likely not as easy as many would think and from that perspective alone it would seem like Twitter would love to adopt a #NOLOGS policy.
However, if we dig a bit deeper into what this data may also be used for, beyond incriminating journalists and activists worldwide it would seem like the chances of this ever happening are slim. According to their Privacy Policy, log data is also used for Fraud, Security and Technical reasons.
Consider that account X is being reported as spam by a high percentage of users, why not cross reference the IP address its been connecting from (or even address block) to other accounts recently being flagged as spam? Simple algorithms like this could potentially be an integral part of keeping Twitter safe and usable. It would certainly seem like sites like Facebook are using similar systems to thwart fraud as well. Consider the following screen shot, captured after Facebook detected malicious activity.
Beyond fraud and security data, it’s hard to imagine that Twitter is not capitalizing off visited link data as well. If that’s the case, adopting a #NOLOGS policy could potentially have financial implications for the company.
It would seem like Twitter understands the situation, and the ferocious opposition that can be felt when privacy is sacrificed for security, but should the question be around Twitter’s logging policy or the US LEA’s desire to be omnipresent?
Either way, it will be interesting to see if the #NOLOGS hashtag trends on or if this mission loses steam and is forgotten. While the privacy of its activist user base is clearly important to Twitter, when you weigh in all options it seems unlikely that they will adopt such a policy.
If Twitter does remain the activist’s communication tool of choice, one thing is clear: it will be increasingly difficult to appease both US LEA’s and the activist/privacy-supporting section of its user base.
Enhance your audit trail logging with TCPWrappers
TCPWrappers performs access control for supported applications when making connections over a network. It also logs this activity to syslog, enhancing the audit trail for hosts running TCPWrappers.
While most UNIX-based distributions these days already come with TCPWrappers, there are some circumstances where one or more servers do not have this feature. If you discover that this feature isn’t installed or utilized, you should consider adding it to ensure that your audit trail logging to syslog is capturing these log messages.
TCPWrappers uses hosts.allow and hosts.deny to control what user, hosts, and/or IP addresses or networks can establish a connection to the respective service/daemon and this activity is logged to syslog. Some programs weren’t compiled to support TCPWrappers and others originally didn’t but have now adopted this functionality.
The severity and facility are all configurable via the main configuration file or within the 2 access control files noted above. The logging level and facility can be set for all services or individually.
Besides logging all the interesting messages, there is a simple and nifty way to monitor access attempts when the service isn’t enabled. That is to have the service/daemon referenced, but to execute /bin/false so that the access attempt is logged, but nothing is executed or no connection is established.
If UNIX-based systems are a part of your critical/sensitive infrastructure, review each system for the existence of TCPWrappers. If it doesn’t exist you should consider adding it and if it does, make sure that all programs that can use TCPWrappers are configured to do so. And, of course, now that this information is logged to syslog, ensure you review these logs for any security, audit, or operational activities that require extra attention or analysis.
Data Breach Disclosure Laws Are Now Long Overdue
Ah, Europe – why do its citizens seem to have to wait forever for action to be taken on issues that seem obvious to everyone else? While they may take some solace from the overdue departure of Signore Silvio Berlusconi (although I’m sure they will miss his ‘unique’ brand of humour – what a card!) it seems they will have to wait longer than expected for the right to find out if their personal information has been compromised.
Earlier this month, the European Commission (EC) announced that it was delaying the release of a new version of its Data Protection Directive – originally scheduled for mid-November – until the end of January 2012. When released, the legislation will install a welcome ‘mandatory data breach disclosure’ ruling across both public and private sector organisations, requiring them to report any breaches to relevant regulatory bodies, such as the UK’s Information Commissioner’s Office (ICO), as well as inform affected individuals. The ruling is expected to have global implications, as the law is likely to also cover non-EU companies that store data on European citizens.
Laws enforcing mandatory data breach disclosure are now long overdue in Europe. Such legislation is already in place in the US, and our recent research shows that the majority of the UK public are dissatisfied with the minimal consequences UK organisations face when they jeopardise sensitive data. 83 percent of the 2,000 UK consumers we surveyed support compulsory data loss disclosure legislation and the delay means they’ll have to wait even longer before this governance is in place.
With an unprecedented number of high profile data breaches occurring in the past year, this will no doubt be a huge frustration to the UK public, who are more prepared than ever to take drastic action against organisations that lose data. Our survey found that 26 percent of respondents were adamant they would never have anything to do with organisations which had lost data as a result of cyber crime, a rise of nine percent when compared to similar LogRhythm research conducted in 2010.
Once mandatory data breach disclosure laws are enforced, organisations will find they need to develop a much deeper insight into the activity taking place across their networks. This is because they will be required to generate accurate notifications which will specifically identify who and what has been compromised. This has been a particular problem in the US, and many companies are forced into issuing blanket breach notifications, which may even overstate the severity of the incident, due to a lack of visibility into their IT systems.
Solving this problem depends on organisations making better use of the log data generated by IT equipment. Both investigating breaches after they occur and detecting them beforehand depend on systems that can automatically collect and analyse 100 percent of log data in real-time. Only this approach can provide the forensic insight required to truly understand how threats penetrate systems and compromise data. With data breach incidents reaching an all-time high this year, it is clear that traditional perimeter security solutions are an inadequate defence. Organisations now require the traceability provided by continuous log data analysis to identify anomalies, formulate damage limitation strategies and generate accurate breach notifications.
However, organisations should not wait for new legislation to obligate them into gaining a better understanding of the IT estate. The high proportion of the UK public in favour of mandatory notification tells us a lot about the lack of trust that exists when it comes to an organisation’s ability to defend against cyber attacks, and when asked if organisations are doing enough to secure customer data, 81 percent did not believe this was the case and that more needed to be done. Clearly it is best practice to be constantly aware of the smallest changes that occur across organisations’ IT systems, which will help to ensure major breaches do not occur in the first place.
Unfortunately online threats are becoming ever more sophisticated and harder to identify. If only IT systems wore undesirable activity as a badge of honour like Italy’s departing premier – it would certainly make the CIOs job a lot easier!
On Its Three Year Anniversary Conficker Still a Top Threat
Recently I was asked to speak about the prevalence of the Conficker worm. I initially scoffed at the idea, remembering that Conficker was discovered in November 2008, and the vulnerability it used to spread was patched by Microsoft in October of the same year…ancient history in the security world. However, after just a little research, I found AV vendors are still considering it to be one of the most prevalent pieces of malware out there.
How can this be? The vulnerability Conficker used to spread was patched 3 years ago! Every AV vendor I know of has been able to detect and remove the worm since then. Many have even issued “Conficker Removal Tools” to assist in the event a system gets in a state where standard AV isn’t working properly. So why is Conficker still a problem?
It really comes down to fundamental security practices (or should I say lack of fundamental security practices). The early variants of Conficker spread by exploiting a vulnerability in the Windows Server Service, then downloading a payload from a remote site. The worm continues to spread via this method, but also by attempting to execute copies of itself on ADMIN$ shares on computers visible on the network, launching a dictionary attack if the shares are protected. In addition, copies are saved to removable media devices and spread via AutoRun.
Any organization with a basic patch management program and AV strategy, both very standard things to have in a defense arsenal, should be protected against Conficker. However, with an ever-expanding mobile workforce, many organizations are losing control over systems connecting to corporate networks, which might be one of the reasons older malware such as Conficker are still prevalent. Even home users that don’t have corporate resources should be running one of the free AV products, and have Windows Updates enabled to ensure their systems stay patched.
So that covers the “now.” What about when the next worm that hits, one that utilizes a zero-day vulnerability that by definition isn’t yet patched, and unlikely to be picked up by many AV engines? This is where SIEM can help. Instead of worrying about detecting the exploit itself, a SIEM can look for general worm-like behavior. Worms are noisy. Once a host is compromised, the worm will continue to try to spread to other hosts on the network, as outlined above. By utilizing advanced correlation rules against this rather noisy activity, specifically rules that target internal network activity, a SIEM can alarm on worm-like behavior, even if the exploit being used to spread the worm is unknown.
Tags: conficker, malware, security, siem
LogRhythm wins "Innovator of the Year" from SC Magazine. "This is not your father's log manager."