SANS ISC: FCC posts Enquiry Documents on Google Wardriving

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Remember back in 2010, Google was in hot water for some wardriving activities, where personal information was gathered from unencrypted  wireless networks found during it's Streetview activities?  Deb wrote this up here ==> https://isc.sans.edu/diary.html?storyid=8794

Well, it looks like the discussion won't die - the FCC has just posted a summary of its findings here, along with some good background and a chronology of events in their investigation ==> http://transition.fcc.gov/DA-12-592A1.pdf

You'll notice that it's heavily redacted.  A version with much less redacting can be found here ==> http://www.scribd.com/fullscreen/91652398

It's very interesting reading.  What I found most interesting in the paper was:

• I thought it was sensible that the engineer didn't go write a new tool for this - they used Kismet to collect the data, then massaged Kismet’s output during their later analysis. Aside from the fact that anyone who's been in almost any SANS class would realize how wrong using the tool was, at least they didn't go write something from scratch.
•  Page 2 outlines the various radio licenses held by Google.  This caught my eye mostly because I'm in the process of studying up for my own license. 
• The suggestion and implementation for the data collection in the controversy came from unnamed engineers ("Engineer Doe" in the paper).  I found it really interesting how the final "findings" document doesn't name actual names - I'd have thought that assigning responsibility would be one of the main purposes of this doc, but hey, what do I know?
• Engineer Doe actually outlined in a design document how the tool would collect payloads (page 10/11), but then discounted the impact because the Streetview cars wouldn't "be in close proximity to any given user for an extended period of time".  The approval for the activity came from a manager who (as far as this doc is concerned) didn't understand the implications of collecting this info, or maybe didn't read the doc, or missed the importance of that section  - though a rather pointed question about where URL information was coming from was lifted out of one critical email.

Needless to say, violating Privacy Legislation "just a little bit" is like being a little bit pregnant - the final data included userids, passwords, health information, you name it.  As they say "close only counts in horseshoes and hand grenades" - NOT in Compliance to Privacy rules !

Long story short, this document outlines how the manager(s) of the project trusted the engineers word on the legal implications of their activity.  I see this frequently in my "day job".  Managers often don't know when to seek a legal opinion - in a lot of cases, if it sounds technical, it must be a technical decision right?  So they ask their technical people.  Or if they know that they need a legal opinion, they frequently don't have a budget to go down this road, so are left on their own to take their best shot at the "do the right thing" decision.  As you can imagine, if the results of a decision like this ever comes back to see the light of day, it seldom ends well.   Though in Google's case, they have a legal department on staff, and I'd imagine that one of their primary directives is to keep an eye on Privacy Legislation, Regulations and Compliance to said legislation.  Though you can't fault the legal team if the question never gets directed their way  (back to middle managment).

From a project manager point of view, this nicely outlines how expanding the scope of a project without the approval of the project sponsor is almost always a bad idea.  in most cases I’ve seen, the implications of changing the scope are all around impacts to budget and schedule, but in this case, a good idea and a neat project (Google Streetview) ended up being associated with activity that ended up being deemed illegal, which is a real shame.  From a project manager's perspective, exceeding the project scope is almost as bad a failure as not meeting the scope.   Exceeding the scope means that either you exceeded the budget or schedule, mis-estimated the budget or schedule, or in this case didn't get the legal homework done on the scope overage.

Take a minute to read the FCC doc (either version).  It's an interesting chronology of a technical project's development and execution, mixed in with company politics, legal investigation and a liberal sprinkling of "I don't recall the details of that event" type statements.  Not the stuff that blockbuster movies are made of, but interesting nonetheless !

We invite your opinions, or any corrections if I've mis-interpreted any of this - please use our COMMENT FORM.  I've hit the high points, but I'm no more an lawyer than "Engineer Doe"
 

===============

Rob VandenBrink
Metafore