The Security Practice

Combating Cybercrime

Hello, Andy Steingruebl here:

We've just published a whitepaper titled "Combating Cybercrime: Principles, Policies, and Programs".

You can read a quick summary at this blog post, or download and read the paper itself.  While we don't believe we have all of the answers to combating crime online, we do believe we've presented a set of principles as well as several workable policy and technology options that will help make progress against this problem.

Please do let us know your thoughts.

Thank you

Do-Not-Track Must First "Do No Harm"

Hello, Brett McDowell here:

Mozilla went on the record over the weekend with their specific proposal for how to implement Do-Not-Track (DNT) mechanisms via HTTP-header (with the goal to enable users to opt-out of Online Behavioral Advertising (OBA) at internet-scale, if they wish).  Here are the relevant links:

Privacy Positioning Blog Post (Alex Fowler):

Firefox Technical Proposal Blog Post (Sid Stamm):

Proposal Itself (header implementation):

Proposal Itself (UI implementation):

Technical Analysis of Do-Not-Track proposals (Mike Hanson):


Mike Hanson's blog post is the best analysis on the topic I've seen so far, but it still fails to call-out anti-fraud tracking explicitly as a behavior that should not be interfered with by DNT.  He lists: advertising, personalization, and metrics as functions DNT should avoid interfering with, but given the nature of the Mozilla DNT proposal, sites still have to implement an interoperable OBA opt-out mechanism to avoid even that level of interference.  Will every browser vendor have their own interface we have to interoperate with to avoid having all "3rd-party tracking" -- which of course doesn't actually mean 3rd-party, but simply means "from domains other than the one in the location bar" -- blocked by their browser?

I continue to be disappointed by the Do-Not-Track discussion as captured by the media and blogosphere for its continued disregard for the security considerations of this new header.  Our concern is not about some geeky, low-level afterthought.  We are talking about a fundamental negative consequence on internet security brought about by an industry-wide knee-jerk reaction to the FTC that is currently poised to remove mission-critical consumer protection mechanisms (commonly used by sites that require user authentication, including but not limited to financial services and commerce) if security considerations remain in the shadows of this policy debate much longer. The internet community must come together and explicitly carve-out anti-fraud tracking as a behavior to sustain, if not embolden, in the post-DNT world.  

Carving-out first-party tracking is a reasonable step that I don't intend to criticize, but it's a blunt instrument that is insufficient for the task.  Anti-Fraud tracking is not always exclusively conducted via first-party cookies, nor is OBA exclusively negated by blocking 3rd-party cookies (as Mike Hanson points out in his post).  Whatever DNT turns out to be, it must be based on a use-and-obligations model, i.e. a mechanism that triggers the required obligation for the specific use being addressed by the mechanism, which is OBA in this case.  I'm pleased to see Mozilla headed in that direction, but there is still a long way to go before we've got this right.  

The core issue is introduced in this sentence from Mike Hanson's post:
"I propose that the user's intent can be captured in a simple rule: If the Do-Not-Track header is present, and the site has a "tracking opt-out" mechanism, the mechanism should be activated. If the site does not have an explicit opt-out mechanism, the user should experience only content from their first-party relationship with the page being viewed."

I interpret the intent of that to mean:

1. Sites must implement an interface between the HTTP "DNT" Header and their current opt-out mechanisms
2. This implementation must be interoperable across all browsers and sites
3. If anything goes wrong and the browser cannot interpret the confirmation from the site that it has implemented it's OBA opt-out mechanism in compliance with the DNT header setting in the browser, then the browser will initiate the "more harmful than helpful" behavior of blocking all but obvious domain-based, first-party content and tracking mechanisms.

Step 3 highlights the nest of issues we need to resolve if we want to ensure the post-DNT-web is better at protecting personal information from unauthorized disclosure than the web we have today.  

Because this is a tractable problem, we are not against the DNT movement per se.  We are against DNT gone wrong.  What we need now is an all-hands standardization effort inclusive of the many proposals, all the various influencers, under a collaborative framework with a proven track record of facilitating timely compromise on thorny standardization issues, to bang out a rough consensus set of policies and protocols for DNT.  This is not a call to stop the DNT effort, but to elevate DNT out of the noise of media coverage and into serious analysis and standardization work... before it's too late to get it right.

How Mine Safety is Like Internet Governance

Hello, Andy Steingruebl here:

There was a great piece on NPR  (a link to some of it here: http://www.npr.org/blogs/thetwo-way/2010/04/safety_agency_to_use_ignored_p.html)  the other day about the MSHA (Mine Safety and Health Administration) and how their enforcement against unsafe mines has been sorely lacking.  One key piece of the story is that essentially the statutory authority granted to the MSHA is to close a mine, or a section of it.  They don’t have the power to levy fines for example, or prosecute individuals doing unsafe things.

As a result, their main weapon is essentially the nuclear option against a mine operator.  They are therefore reluctant to use that authority, and so they have instead created a system of letters-of-pending-action or somesuch.  Under these they indicate to a mine operator that they are getting close to a breach of their requirements, and they give them a cure timeframe.  Because mine operators can appeal any judgments, this ends up being a real obstacle to credible enforcement.  Historically we’ve seen the same things from the FAA.  They are loathe to write up formal findings because they have the possibility of causing major harm to an airline, rather than just getting them to modify the offending behavior.

 ICANN has a similar problem with policing their registrars.  historically the only penalty they can impose is removing a registrar’s accreditation.  This is the nuclear option.  They have typically been loathe to fully remove a registrar, and so we end up with bad registrars in the system. We've seen them step up the enforcement recently, but I think these are probably still enforcements against only the most egregious offenders.

The lesson for us in working to craft internet governance and regulations is that we need to understand this dynamic between regulator and regulated-entity, and create flexible schemes that allow the regulator to effectively police, without each policing action being a nuclear option, and thus causing regulated entities to fight every judgment action in court, etc.

Disclosure policies – what constitutes “responsible” disclosure, vs irresponsible disclosure?

Hello, Michael Barrett here.

Anyone who works in the information security business would have to have been in full Rip Van Winkle mode to have missed the debate about disclosure policies over the last several years.  The agonizing that we have collectively done over what constitutes “responsible” disclosure would have been greatly admired by a mediaeval philosopher, more accustomed to debating how many Angels can dance on the head of a pin.

2007 marked something of a watershed in that the practice – which had previously been kept pretty quiet – of companies, such as iDefense, purchasing vulnerabilities on the black market turned into at least a publicly visible grey market.  While there was some debate about it, I was personally surprised by how little the ethics of this were discussed.

2007 also marked something of a change in that it was the first year wherein e-commerce websites, such as PayPal, started publishing clear policies as to what they consider to be responsible.  We published our own in late 2007, and it can be found at:

https://www.paypal.com/us/cgi-bin/webscr?cmd=xpt/cps/securitycenter/general/ReportingSecurityIssues-outside

While I wouldn’t necessarily describe our own policy as perfect, a great deal of work went into it.  Actually, considering how short the policy is, that statement may seem surprising, but nonetheless it is the case.

We’re very interested in hearing feedback from the community as to whether we’ve got this policy right, or close to it.  We’re certainly prepared to tweak it, if we hear convincing arguments that there are good reasons for doing so.  There are a couple of areas of our policy where we agonized for some time.

We frankly fudged over the length of time we have to ensure that a particular vulnerability is fixed.  I was personally in favour of describing the maximum period that we’d commit to; however, the team more or less unanimously over-rode me on that one.  In the end, we settled on the weasel words “reasonable time” instead.  What convinced me was that:

1) In order to give a publicly useful time commitment, we would have to explain our entire vulnerability classification methodology (which would be several times longer than the policy itself), because what constitutes “reasonable” isn’t basically absolute but is instead situational.  For example, in the case of an extremely serious vulnerability (an SQL injection flaw, for example), we’d almost certainly respond with extreme speed, taking the offending page down, even if there was non-trivial business impact.  However, an extremely difficult-to-exploit and scope limited XSS, we would probably fix in a more leisurely fashion – especially if it’s one where we can easily implement automated monitoring to detect if it ever gets exploited.  (By the way, this is one of the key differences in vulnerabilities in websites vs. vulnerabilities in distributed software – by definition, we have much more immediate control over how we respond.)

2) Having said that, we also don’t necessarily have direct control over our development and functionality rollout priorities.  (Shocking, eh?  Who knew that Information Security isn’t the Centre of the Universe?)  Imagine a case for a low priority issue, where we were doing automated monitoring.  Of course, we’d still have it in the priority queue for fixing but we’d frankly not necessarily fight too hard if our dev teams de-prioritized the fix over more important business enhancements – especially if there was no sign of any exploit on the horizon.

While I grudgingly accepted all of these arguments, my concern was and is that “reasonable” is in the eye of the beholder.  While we try to be responsible and prudent, I can certainly imagine other organizations whose functional definition of reasonable might translate to “when Hell freezes over”.  I’d rather be able to craft a policy that, if adopted by one of those companies, would effectively change their behaviour.  Alas, in that regard, I don’t believe we’ve succeeded yet.  The obvious question is whether it’s actually possible to come up with a short pithy policy that also meets that particular litmus test.  I’m not sure that it is.

More on disclosure in a few days, where I’ll talk about the really contentious aspects…