CAUCE

Facebook, their Walled Garden, and McAfee Anti-Virus – What Really Happened

On Sunday, a number of Facebook users reported being locked out of the system. When they attempted to log in they were presented instead with the a series of screens, informing them that their computer was infected, and providing a link to a free scanning service by McAfee antivirus software.

Being locked out upset people to no end, because it was the first they had heard about their computer being infected.

It appears that Facebook users on a grand scale are receiving a notice that their account is temporarily locked and could be infected with a virus. These users are then encouraged to download a free tool by McAfee to scan their system. There has been much speculation on the issue. Our best guess is that there is a bug in Facebook's filters or algorithms that is yielding a false positive malware result for a large portion of these users. We have reached out to Facebook regarding the matter and will update this thread if we hear anything back.
Other users with Mac computers insisted they were safe.

If only that were true. Over just these past few weeks we have read about Facebook itself being hacked due to a vulnerability in Oracle’s common cross-platform (Windows, Mac, UNIX) software component Java. Media-player Adobe Flash has had a tough time of it too being repeatedly patched, then re-hacked within days, and that runs on all sorts of computers. One Adobe rep, looking very tired, said recently that things were so busy with security issues staff had taken to sleeping at the office. Like, as in ‘moved in’.

Our point? It was entirely reasonable to think that Facebook was detecting infected computers trying to log into their systems.

Wait what? Facebook is scanning their users computers?

Yes, they are. This isn’t a new activity. For example, Google and Facebook helped quell a massive infection called DNSChanger by diverting infected users to special pages with disinfection information U.S. Cable ISP behemoth Comcast also scans their users’ computers and in the case of repeated, untreated infections, user accounts are placed in a so-called ‘walled garden’ limiting Internet access until they can be fixed.

Walled Gardens are a reasonable approach, and an effective way to deal with the rampant levels of compromised computers that can damage networks, and the users’ themselves, by stealing personal information on the machine. In fact, CAUCE has representation on the FCC’s Communications Security, Reliability and Interoperability Council (CSRIC) working group advocating a similar approach industry-wide.

CAUCE has also been involved in parallel discussions in Canada, where the idea is still nascent, but is likely to take hold shortly. But what does all this have to do with Facebook Users? Facebook scans computers connecting to their network for infections, and places compromised user computers in a walled garden until the problem can be remediated. They offer free tools to help. They write certain rules for the scanning engine to detect the infections Reasonable enough. According to a Facebook rep., speaking on condition of anonymity said the problem last Sunday was a new employee wrote rules that were a bit too aggressive, and they incurred many false positive results, falsely indicating computers were infected when they were not. After a couple of hours, the error was caught, and initially they withdrew the rules, and then began to find, and reverse the suspended status of those users they had initially blocked. This lead to what users were experiencing– log in once, you are told you are infected, log in again, no such notice. This is what is known in the computer industry by the technical phrase ‘oops’. CAUCE congratulates Facebook (and others) on their efforts to help mitigate computer compromises by this approach. While it is irksome, and sometimes scary to be locked out, and told your computer is infected, the worst-case scenario is that you were unable to post cat and baby photos for a short time on Sunday, and had to run a harmless anti-virus scan.

CAUCE, MAAWG, London Action Plan release "Best Practices to Address Online and Mobile Threats" Report

New Online and Mobile Best Practices Clarify Business and Governmental Security Tactics




Baltimore, Oct. 24, 2012 – A cooperative international report available today outlines
Internet and mobile best practices aimed at curtailing malware, phishing, spyware, bots
and other Internet threats, and provides a thorough review of current and emerging
threats.  “Best Practices to Address Online and Mobile Threats” is a comprehensive
assessment of Internet security as it stands today and explains in non-technical language
the proactive steps that can help mitigate risks, according to the report’s two major
contributors, the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) and the
London Action Plan (LAP).

The report is also one of the first global efforts to encourage governments to deploy best
practices, which are more often associated with businesses.  It focuses on four major
areas of concern: malware and botnets, social engineering and phishing, IP and DNS
exploits, and mobile threats. To encourage government participation, it has been
presented to the 34-member country OECD (Organisation for Economic Co-Development) for
review.

“Best Practices to Address Online and Mobile Threats” draws on the tactics that have
proven effective over the past decade to reduce online risks, then augments these with
forward-thinking recommendations for emerging vulnerabilities, such as mobile text spam
and Web abuse. The comprehensive report is available here:



Download Best_Practices_to_Address_Online_and_Mobile_Threats_(Oct_2012)

The report is also available via the London Action Plan site and by way of the Messaging
Anti-Abuse Working Group site.

“As a globally cooperative effort, the report brought together an unprecedented team of
experts who outlined safe computing tactics in uncomplicated, accessible language for
end-users, large and small businesses, and governments. This is also one of the first
efforts to update industry recommendations recognizing that public agencies are important
online enterprises, and just as companies need to implement best practices, so do
governments,” Alex Bobotek, M3AAWG co-chairman said.

CAUCE President John Levine noted "We were honored to work with Industry Canada, M3AAWG,
and the other organizations. Online security is such a massive problem that working
partnerships among governments, business, and non-profits such as CAUCE is the only
logical way forward to deal with these issues."

The international community collaboratively stepped up to generate the report in a
public-private partnership led by André Leduc, Manager of the National Anti-Spam Coordinating
Body at Industry Canada. Industry experts from M3AAWG, LAP and other
organizations, such as CAUCE, contributed to it.
CAUCE President John Levine, and Executive Director Neil Schwartzman were part of the
Paris delegation that presented the report to the OECD committee on consumer protection,
it was also reviewed by the Working Party on Information Security and Privacy (WPISP).

Online threats are evolving as Internet and mobile technologies play a more vital role in
many business models, attracting cybercriminals who target users on popular platforms such
as laptops, tablets, smartphones and other handheld devices. As the Internet economy
grows, implementing the best practices detailed in the report will help reduce illegal
activities such as spam, phishing, malware and spyware distribution, botnet deployment,
the redirection of Internet traffic to malicious websites and denial of service attacks.

CRTC Issues CASL (Canada's Anti-Spam Law) Regulation Guidelines

The Canadian Radio-television and Telecommunications Commission today issued two important guideline documents related to their previously-published Regulations

Guidelines on the interpretation of the Electronic Commerce Protection Regulations (CRTC)
Compliance and Enforcement Information Bulletin CRTC 2012-548
PDF version
Additional reference: Telecom Regulatory Policy 2012-183
Ottawa, 10 October 2012

and

Guidelines on the use of toggling as a means of obtaining express consent 
Compliance and Enforcement Information Bulletin CRTC 2012-549
PDF version
Additional reference: Telecom Regulatory Policy 2012-183
Ottawa, 10 October 2012

As well we are told that the second-round iteration of the Industry Canada Regulations will be published later this month.

Inbound Email Filtering Sued Over Privacy Issues, This Time in Canada

In a case that parallels many of the aspects of the three cases filed in July 2012 in California, against Google & Yahoo!,  retiree Wayne Plimmer of Sechelt, British Columbia filed a class action suit against Google on October 4, 2012.

Here is a copy of the complaint :  Download PlimmerV.Google

The suits alleges that Google has breached sections 1 and 3 of the British Columbia Privacy Act R.S.B.C. 1996 c. 373 and s.52 of the Federal Competition Act R.S.C. 1985 c. C-34

Some news coverage notes that the class has not yet been approved (anyone in British Columbia who has sent email to a Gmail account), and that should this lawsuit be successful, this may prohibit the use of anti-virus and anti-spam software on inbound mail. The suit also alleges that Google invaded users’ privacy, violated solicitor-client, physician-patient, pastor-penitent and journalist-source privilege, and infringed upon copyright.

CAUE President has blogged about the U.S. Federal and California cases here and here 

The BC Privacy Act reads:

CASL Slides into 2013

We have all been patiently waiting for new regulations on CASL, they were expected before the governments summer vacation session, but sadly we will continue to wait.

Several industry organizations have been telling members that the CASL Regs V2 will slide into the Fall before being published. Factoring in this delay we are expecting to see CASL's enforcement begin in mid-2013. Thus providing additional time for organizations to become compliant with the Canadial Anti-Spam Leglislation. We have also reached out to our contacts at Industry Canada and recieve confirmation of the delay in publication of these regulations.

To Recap CASL's Journey:

• 2004 - Canada's Federal Anti-Spam Task Force (FAST-F) is formed
• 2005 - FAST-F's recomedations to the Government are published
• 2009 - Electronic Commerce Protection Act (Bill C-27) ECPA is introduced
• 2010 - May: Fighting Internet and Wireless Spam Act (Bill C-28) FISA
• 2010 - Decemnber: Bill C-28 is passed into Law with no short name
• 2011 - CASL becomes the common name for Bill C-28
• 201? - Enforcement of CASL to begin... ?

Stay up to date on CASL here, or by subscribing to updated on the fightspam.gc.ca website.

CRTC CASL Regulation Summary

[originally posted at Emailkarma. Written by CAUCE Director Matt Vernhout]

We have found what appears to be an official version of the Canadian Radio-Television and Telecommunications Commissions (CRTC) Canada's Anti-Spam Law CASL regulations on the Canadian Employment Pension Law website along with a brief overview of the regulations.

Here is a quick summary:

Information to be included in an email message has been clarified to included these key identifiers: CEM’s need to be the name by which the person sending the message conducts business, for third party messages you should use the name by which the third party carries on business, and include a statement indicating which person is sending the message and which person on whose behalf the message is being sent.

Contact and mailing address has also been clarified to be; the mailing address of the sender and either a telephone number providing access to an agent or voice messaging system, an email address or a web address of the person sending the message or the person on whose behalf the message is sent.

When it is not possible to include unsubscription information in the CEM you may included that information on a page on the World Wide Web that is readily accessible by the person to whom the message is sent at no cost to them by means of a link that is clearly and prominently set out in the message. This is a big deal for Mobile* messaging and Social Media messages as these platforms and character limitations do not always allow for all of the previously required information… I can’t ever see this being an issue for an email message though.* Mobile Keywords STOP will remain a requirement

All unsubscribe mechanisms referred to in paragraph 6(2)(c) of the Act must be set out clearly and prominently and must be able to be readily performed.

A request for consent has been clarified to include oral or written consent and must be sought separately for each channel (SMS, Email, etc…) of the Act and must include the key identifiers listed above (point 1) along with a a statement indicating that the person whose consent is sought can withdraw their consent at any time.

Computer programs that perform one or more of the functions listed in subsection 10 (5) of the Act [causing a computer system to operate contrary to reasonable expectations] must have a separate consent sought from any other information provided in a request for consent and the person seeking consent must obtain an acknowledgement in writing from the person from whom consent is being sought that they understand and agree that the program performs the specified functions.

What’s Next with CASL?
We are still waiting on the regulations from Industry Canada that will hopefully clarify a number of the outstanding issues and questions that they received during last years comment period. We are expecting to hear from them in the next couple of weeks (Maybe early April) when a new 30 day comment period is scheduled. After these comments are reviewed final regulations will be presented and an enforcement date will be set.

The big question is still outstanding – When is CASL coming into force?

Latest word on this will be at or near the end of Q3 2012 (around October), but the regulations from Industry Canada will clarify this.

Download the CRTC’s Regulations HERE [PDF]

CRTC responds to stakeholder concerns with final regulations under CASL

The Canadian Radio-television and Telecommunications Commission (CRTC) has finalised its regulations under Canada's Anti-Spam Legislation (CASL), resulting in a set of rules that are more balanced, reasonable, and in line with the objectives of the legislation. The new requirements are also more consistent with the requirements under the U.S. CAN-SPAM Act of 2003, with which many senders are already familiar.

CASL creates rules for sending commercial electronic messages (CEMs) and installing computer programs. It also establishes a general prohibition against the alteration of transmission data and is expected to come into force later in 2012. Industry Canada is also responsible for developing regulations, and should be posting another version of its regulations within the next month or so.

The CRTC originally posted draft regulations for comment in June of 2011, which generated a significant number of responses, many of which pointed to the potential challenges for anyone sending email or other electronic messages for business purposes. With these final regulations the CRTC [PDF] has addressed a number of issues raised by stakeholders:

Consent in writing - A request for consent is no longer required to be in writing; rather, consent can be requested orally. This does not give free reign for senders to assert that they have consent without evidence, however, as anyone claiming to have consent bears the burden of proving it under the legislation.

Information to be included in a request for consent/CEM - The CRTC has dialed back the quantity of information to be included when requesting consent and in a CEM. A sender is now required to provide:

the name of the person seeking consent or sending the CEM (or the person on whose behalf consent is sought or sent, if different); (The regulations specify that a person must be identified by the name by which the person carries on business, if different from the actual name of the person).

if the message is sent on behalf of another person, a statement indicating who is or will be sending and on whose behalf the message is or will be sent;

the mailing address and either a telephone number, an email address or web address of the person sending (or on whose behalf) the message is or will be sent;

when seeking consent, a sender must indicate that the individual can withdrawal consent at any time.

The draft regulations would have required a person sending a CEM to provide every electronic address that person uses, as well as a physical, mailing and web address. Furthermore, they would have required a CEM to provide all of that information for the person sending as well as every person on whose behalf the message is sent, which would have been particularly onerous where a CEM includes content for several advertisers, such as in a newsletter (now every person must be identified by name, but other identifying information is only required for one person). Finally, the CRTC has removed the requirement for  senders to indicate that a recipient could withdraw consent from any of the many forms of contact information provided to the recipient in a request for consent or CEM. Overall the changes to these provisions are very positive.

Unsubscribe mechanism - the CRTC regulations now simply state that the unsubscribe mechanism in a CEM "must be able to be readily performed". The draft regulations were more prescriptive, stating that the mechanism "must be able to be performed in no more than two clicks or another method of equivalent efficiency".

Now that the CRTC regulations have been finalized, businesses have much more information about how to design marketing campaigns that are CASL-compliant. In particular, these rules provide more of the necessary details to ensure that consent obtained now will be valid once CASL comes into force. The Industry Canada regulations may also be relevant in some circumstances; for example, where one person is seeking consent on behalf of an unknown third party.

- Shaun Brown

Canada moves ahead on the Spam Reporting Centre

One of the important parts of Canada's new anti-spam law (CASL) is the Spam Reporting Centre. It is intended to serve multiple functions, including to help the government track the effectiveness of its anti-spam enforcement, to collect data to bring legal cases under CASL, and, with appropriate measures to protect individuals' privacy, to allow access to academic researchers.

As reported in this article at canada.com, Industry Canada asked for bids to build and operate the SRC, and is now evaluating the bids and will presumably select a winner in the near future. CAUCE assisted IC in creating the framework and bidding requirements for the SRC.

J.D. Falk - In Memoriam

Jesse David “J.D.” Falk - May 24, 1974 - November 16, 2011

It is with the heaviest of hearts that CAUCE must make note of the passing of one of our own. J.D. Falk was a founder of CAUCE, and one of the nicest people in the anti-spam community.

Besides being a board member of CAUCE U.S. since its inception in 1997, he went on to support the organization as a member of the CAUCE North America Executive. His tireless efforts helped to make CAUCE what it is today.

During his career, J.D. worked at Erols, Priori, Critical Path, MAPS, Yahoo!, Microsoft, and Return Path, but perhaps his most important contributions in fighting online abuse were to the Messaging Anti-abuse Working Group, wherein his tireless efforts organizing the MAAWG meetings were literally immeasurable.

J.D. was a prolific author, his writing published on CircleID, at his employer Return Path’s website, and in the RFC process at the Internet Engineering Task Force (IETF). His contributions went far towards making the Internet a better, safer place for us all.

J.D. was one of a kind,” said CAUCE President John Levine. “Everyone knew him, everyone trusted him, and everyone knew they could count on him to see the real issues.”

J.D. was so very well respected that a professional standards organization, the Internet Engineering Task Force, pulled out all the stops to honor him in his last days. His friends and colleagues Dave Crocker and Murray Kucherawy explain:

The IETF publishes technical specifications and related documents through a series that was started with the beginning of the Internet, called Request for Comments (RFC); the name reflects the Internet's origins as a research body more than 40 years ago.

JD had a document in the approval process (see notice below). J.D.'s document had already been approved by the IETF and it was in the last stages of document editing by the RFC staff.  A small group of us asked whether they could expedite the process, more quickly than the expected two months. The IETF staff recruited a technical editor at 1:30am, her time, in New York and she completed the work by the end of the day. J.D. was shown this final draft for his approval, hours before he passed away.

Although the reason was extraordinary, this sort of willingness to help has always been at the core of this small Internet community that JD had joined, and contributed to, throughout his professional life.

J.D. died before his time from cancer. His intelligence, gravitas, good humor and considered opinions were invaluable, CAUCE, and the Internet community, are the poorer for his passing.

CAUCE extends our most heartfelt of condolences to his family and his friends.

Please feel free to share your memories of J.D. Falk at http://jdfalkmemorial.org/

Please read these tributes as well:

Return Path

MAAWG

CircleID

A collection of J.D.'s technical writing can be found at Return Path's Received: Blog

 

From: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>

Subject: RFC 6449 on Complaint Feedback Loop Operational Recommendations

Date: 16 November, 2011 11:58:54 PM EST

To: "ietf-announce@ietf.org" <ietf-announce@ietf.org>, "rfc-dist@rfc-editor.org" <rfc-dist@rfc-editor.org>

Cc: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>

A new Request for Comments is now available in online RFC libraries. 

       RFC 6449

       Title:      Complaint Feedback Loop Operational Recommendations 

       Author:     J. Falk, Ed.

       Status:     Informational

       Stream:     IETF

       Date:       November 2011

       Mailbox:    ietf@cybernothing.org

       Pages:      31

       Characters: 75139

       Updates/Obsoletes/SeeAlso:   None

 

       I-D Tag:    draft-jdfalk-maawg-cfblbcp-03.txt

       URL:        http://www.rfc-editor.org/rfc/rfc6449.txt

 

Complaint Feedback Loops similar to those described herein have

existed for more than a decade, resulting in many de facto standards

and best practices.  This document is an attempt to codify, and thus

clarify, the ways that both providers and consumers of these feedback

mechanisms intend to use the feedback, describing some already common

industry practices.

 

This document is the result of cooperative efforts within the

Messaging Anti-Abuse Working Group, a trade organization separate

from the IETF.  The original MAAWG document upon which this document

is based was published in April, 2010.  This document does not

represent the consensus of the IETF; rather it is being published as

an Informational RFC to make it widely available to the Internet

community and simplify reference to this material from IETF work.

This document is not an Internet Standards Track specification; it is

published for informational purposes.

 

INFORMATIONAL: This memo provides information for the Internet community.

It does not specify an Internet standard of any kind. Distribution of

this memo is unlimited.

 

This announcement is sent to the IETF-Announce and rfc-dist lists.

To subscribe or unsubscribe, see

 http://www.ietf.org/mailman/listinfo/ietf-announce

 http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

 

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.

For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

 

Requests for special distribution should be addressed to either the

author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless

specifically noted otherwise on the RFC itself, all RFCs are for

unlimited distribution.

 

The RFC Editor Team

Association Management Solutions, LLC

How to Prevent (and mitigate) Data Breaches

Cisco's Michael Sanchez published a great piece called 5 Steps for avoiding data breaches.

We tweeted, plussed, and re-posted this elsewhere, and at the encouragement of SURBL's Jeff Chan, here's a blog post about this practical advice. (Do read the article in its entirety)

Step 1: Document where your data is stored and how it is accessed.
Step 2: Identify the level of protection your data needs.
Step 3: Secure your company’s data.
Step 4: Create a disaster recovery plan.
Step 5: Know what to do if you experience a data breach.

Since we are talking about data breaches, it should be noted that Canada is now considering a bill, C-12, 'An Act to amend the Personal Information Protection and Electronic Documents Act' that provides for mandatory notification of breaches.

C-12 is the re-tabling of bill C-29, a bill that died on the order table last year; it is a companion to C-28, Canada's Anti-spam Law; it also has provisions to allow Canadian law enforcement to share data and evidence with agencies outside of Canada, and even among themselves, something that is currently illegal under PIPEDA.

CAUCE supported C-29, and of course supports the passage of C-12. Given the Conservative majority, it is expected that C-12 will pass this legislative session.