STE WILLIAMS

The Payment Card Industry (PCI) Security Standards Council (SSC) Thursday released PCI 3.0, the latest version of the council’s security compliance requirements for businesses that accept credit and debit cards.

Available now on the PCI SSC website (PDF), version 3.0 becomes effective on Jan. 1. Version 2.0 will remain active until Dec. 31, 2014, to ensure adequate time for organizations to make the transition.

Many of the key changes to the guidelines are designed to make compliance more of a regular process, rather than a report on a company’s compliance at a specific point in time, according to the council and other experts.

“Version 3.0 will help organizations make payment security part of their business-as-usual activities by introducing more flexibility, and an increased focus on education, awareness and security as a shared responsibility,” the PCI Council says. “Overall updates include specific recommendations for making PCI DSS part of everyday business processes and best practices for maintaining ongoing PCI DSS compliance; guidance from the Navigating PCI DSS Guide built in to the standard; and enhanced testing procedures to clarify the level of validation expected for each requirement.”

“PCI DSS is stressing that their compliance standard is not a set-it-and-forget-it mentality,” says Joe Schumacher, security consultant at Neohapsis, which helps enterprises with PCI assessment.

“Some important areas in this new mentality focus on security processes,” Schumacher says in a blog. “For example, entities should be validating on their own that controls are implemented effectively for applicable businesses processes and related technologies. Some specific examples related to this new mentality focus on antivirus definitions, logging, vulnerability signatures and ensuring that only appropriate services are enabled on systems.

“With this new mentality, entities should look to take corrective actions when compliance gaps are identified so that PCI DSS compliance can be maintained at all times and not wait until their [auditor] comes to validate their compliance.”

Some experts said the new guidelines don’t go far enough.

“Overall, the council has made some excellent improvements to the standard, but the risk management area of PCI 3.0 still needs more work,” says Michael Aminzade, director of compliance delivery at Trustwave. “The main area of concern is that even though the new standards reference risk management strategies that must be met, the standard doesn’t enforce companies to adopt any of those strategies. In particular, the standard doesn’t address the fact that risk assessments need to be done by an industry-certified professional and are only performed on an annual basis. Also, PCI DSS 3.0 does not include any changes surrounding mobile security.”

Have a comment on this story? Please click “Add a Comment” below. If you’d like to contact Dark Reading’s editors directly, send us a message.

Article source: http://www.darkreading.com/management/new-version-of-pci-compliance-guidelines/240163765

Seattle, WA and Orlando, FL – November 11, 2013 – The Cloud Security Alliance continues to build its agenda for the upcoming Cloud Security Alliance Congress, adding a number of notable and heavily debated presentations featuring some of the industry’s most progressive thought leaders, addressing the most critical issues in cloud computing. This year’s event, happening December 4-5 in Orlando, FL, will feature more than nearly 60 presentations and workshops on topics including the security of U.S. cloud providers, compliance, policy, mobile and big data. Attendees will gain first-hand access to all presentations, and exclusive access to authors of each report through one-on-one discussion and featured interactive presentations.

Featured panels and topics include:

Are US Cloud Service Providers 
Insecure – A Technical Look: 
Jon-Michael C. Brook, Former Cloud and Security Architect at Symantec, will dive into the history of protectionism and tariffs and EU Privacy legislative background. He will then bring to light common arguments of US privacy invasions along with cloud service providers principal protection mechanisms, reference architecture examples and security evaluations.

Identity Security Automation to Stay Ahead of Nation State Attacks: Today’s massive infrastructures are leveraged on user as well as embedded credentials and certificates. Most cloud providers pay little attention to the internal management of these identities and risk serious damage due to periodic perimeter breaches caused by phishing, malware, and other intrusions. Philip Lieberman, President, Lieberman Software will inventory some nation-state attack points, provide guidance on remediation, and describe next generation automation to eliminate these threats from day 1 via rethinking how identity security is managed internally.

The Cloud House of Cards: Accountability vs. Instant Gratification?

Francoise Gilbert, Esq., CIPP/US, Managing Director, IT Law Group will speak to the legal implications of the cloud multi-layer environment, including the taxonomy of cloud services contracts and their dependencies. In outlining the accountability requirements in the different legal systems worldwide, Gilbert will provide the audience with insight on how accountability affects the cloud environment and the legal and technical requirements in performing due diligence, contracting and auditing cloud services.

Big Data, Big Security Questions – Securing Petabytes of Data: Peter Guerra, Senior Associate, Booz Allen Hamilton will address what the Big Data security problem is and how to address it with new architectures. Attendees will also be given access to case studies that look at understanding data cloud security ecosystems.

Trusting Mobile Users in the Cloud: Can We Learn from Past Authentication Failures?

Phillip Dunkelberger, CEO, Nok Nok Labs, will provide insights into business and consumer

challenges with online/mobile authentication
 including original research into the scale of the authentication challenge
 along with future considerations of the mobile requirements and emerging technologies.

Key Considerations to Moving Enterprise Applications to the Cloud: Dan McNerney, SVP, Global SAP Services, Freeborders Corporation will lay out how to architect the right solution including security, compliance and accessibility and what the key success criteria looks like. He will also share how to securely transition and manage enterprise and business critical applications to cloud.

How to Respond to Cloud Security Incidents: Kristy Westphal, Director, Security Operations, T-Systems North America will address the importance of customer and vendor roles, how to conduct tests to find holes in the process, recommended processes and templates, and necessary contractual statements and recommended policies.

Cloud Security Alliance Congresses continue to be the industry’s premier gathering for IT security professionals and executives who must further educate themselves on the rapidly evolving subject of cloud security. In addition to offering best practices and practical solutions for remaining secure in the cloud, this year’s fourth annual U.S. CSA Congress will focus on emerging areas of growth and concern in cloud security. Attendees will gain exposure to industry-specific case studies that will help them learn and leverage best practices used by their peers in moving to a secure cloud.

Article source: http://www.darkreading.com/management/csa-annual-congress-to-draw-industry-att/240163783

NEW YORK, Nov. 11, 2013 /PRNewswire/ — Light Reading, UBM Tech’s market-leading online community for the global communications sector, is embarking on a month of mobile network security coverage, including a live message board discussion with a leading industry analyst that precedes a focused one-day conference on the topic in early December.

On Thursday, December 5, a number of industry specialists will join Heavy Reading senior analyst Patrick Donegan, an expert in network security challenges facing wireless service providers, to present “Mobile Network Security

Strategies: New Threats, New Opportunities.” This one-day event will be held at the Westin Times Square Hotel in New York City on Thursday, December 5, and is focused on the security vulnerabilities facing mobile network operators as they roll out and turn on their 4G LTE networks.

“Most mobile operator strategists, network planners, and engineers don’t have full visibility into the malicious traffic that’s going through their network,”

says Donegan. “We know that, because a lot of the security experts at the mobile operators will admit as much. This event is a unique opportunity to separate out the hype from the reality of cybersecurity attacks as they impact the mobile operators’ infrastructure assets and customers. And it’s a unique opportunity to understand the options for mitigating new security risks as LTE is scaled up into a mass market service.”

The conference agenda includes panels, presentations, and keynotes from a range of perspectives in the industry. A morning keynote from Sanjay Macwan, VP of Mobility and Cloud Security for ATT’s Chief Security Organization, will address the company’s perspective on key threats and attack vectors. In the afternoon, John Marinho, VP of Technology and Cybersecurity at the CTIA, will discuss the CTIA’s Cybersecurity Working Group framework. Additional presentations include specialists from Verizon, NIST, Symantec, Infobox, Arbor Networks, Cloudmark, Nokia Solutions and Networks, Juniper Networks, Nominum, and Alcatel-Lucent. For more details, see http://events.lightreading.com/mnss/.

In advance of the December event, Donegan is hosting in a “live chat” on a special Light Reading message board this month, which can be found at http://www.lightreading.com/messages.asp?piddl_msgthreadid=57405. During that real-time engagement, which takes place at 11:00 a.m. EST (8:00 a.m. PST) on Thursday, November 14, on the website, Donegan will be available to answer live questions from the Light Reading community on mobile network security issues.

Anyone who is registered for the Light Reading site can participate. (Light Reading registration is free – see

http://w1.lightreading.com/?ngAction=register.)

Also in the run-up to the December event, Light Reading will publish a series of articles highlighting some of the challenges facing security-conscious mobile operators. All those articles may be found at Light Reading’s Mobile Security

section: http://www.lightreading.com/mobile-security.asp.

Contact:

Ray Le Maistre

Editor in Chief, Light Reading

[email protected]

Carly Cohen

Marketing Coordinator, Light Reading

[email protected]

About Light Reading

Light Reading (www.lightreading.com) combines its research-led online communities and targeted events portfolio to help those in the global communications industry make informed decisions. Lightreading.com is the ultimate source for telecom analysis for more than 300,000 subscribers each month, leading the media sector in terms of traffic, content. and reputation.

Light Reading produces targeted communications events and focused one-day conferences each year for cable, mobile, and wireline executives across five continents.

About UBM plc

UBM plc is a leading global business media company. We inform markets and bring the world’s buyers and sellers together at events, online, in print and provide them with the information they need to do business successfully. We focus on serving professional commercial communities, from doctors to game developers, from journalists to jewelry traders, from farmers to pharmacists around the world. Our 6,000 staff in more than 30 countries are organized into specialist teams that serve these communities, helping them to do business and their markets to work effectively and efficiently. For more information, go to www.ubm.com

Article source: http://www.darkreading.com/mobile/light-reading-highlights-mobile-network/240163784

IRVINE, Calif., Nov. 7, 2013 – SecureAuth, a leading provider of identity enforcement technology for the enterprise, today announced the worldwide expansion of its partner program, utilizing a three-tiered partner level based on margins, sales volume, and co-marketing opportunities. The latest partners to join the program include Milestone Systems within North America, B2BCOMM in PanAsia, and Cert2Connect in Europe, the Middle East, and Africa (EMEA). Cert2Connet and SecureAuth recently completed an engagement with Swarovski to implement two-factor authentication and single sign-on for cloud applications.

“There is a great need for SecureAuth IdP as more organizations – from large government agencies to the SMB market – are moving resources to the cloud and allowing company data to be accessible via mobile devices and mobile apps,” commented Craig Lund, Chief Executive Officer at SecureAuth. “Combined with our direct sales team, in the last quarter alone we have seen a 50% growth in our pipeline due to our growing partner program and market need.”

Mark Greer, President and CEO at Milestone Systems, a value-added integrator of network security equipment and services, remarked, “There is a growing number of security threats bombarding financial sites via data connectivity and SQL injection attacks. We partnered with SecureAuth for its unique ability to offer a streamlined user experience while meeting stringent security requirements using two-factor authentication and single sign-on for mobile, cloud, and network applications.”

See the complete list of resellers, and learn more about joining the SecureAuth World Partner Program here.

About SecureAuth

Located in Irvine, California, SecureAuth is a technology leader providing 2-Factor Access Control to mobile, cloud, web, and network resources, serving over 10 million users worldwide. The SecureAuth IdP all-in-one, completely scalable solution manages and enforces access based on existing user entitlements. For the latest insight on enterprise security, follow the SecureAuth Blog, follow @SecureAuth on Twitter, or visit www.secureauth.com for additional information.

Article source: http://www.darkreading.com/intrusion-prevention/secureauth-expands-worldwide-partner-pro/240163785

We’ve written about Google’s “Wi-Spy” saga many times before.

And even when we’ve covered a story that suggested that the issue would at last get closure, we’ve said, “Betcha this won’t be the last of it.”

Of course, in just the same way that eventually there isn’t any more toothpaste in the tube, we’ll lose that bet some day.

But not yet, and definitely not this week.

That’s because Google is back in the firing line yet again, years since this all started, this time from Brazil.

The story so far

First, however, here’s the saga so far, or as much as I can remember of it, and not necessarily in chronological order (it all gets a bit hazy after a while).

THE GOOGLE WI-SPY STORY AS A HAIL OF BULLETS, BY P DUCKLIN

• Google’s Street View cars collect Wi-Fi access point information in bulk for geolocation purposes. (Home and business access points tend to stay put, with the same name, for months or years.)

• In 2010, it emerged that for the several years, Google had been sucking up your Wi-Fi payload data at the same time as locating your access point.

• Some Privacy Commissioners decided they didn’t like this and ordered Google to destroy the data at once to prevent its abuse.

• Some Privacy Commissioners decided they didn’t like this and ordered Google to retain the data for investigative purposes.

• Google denied it had collected payload data.

• Google changed its mind and decided that it had collected payload data.

• Australia dubbed it the “single greatest breach in the history of privacy,” but ironically found that local laws didn’t allow any action against Google.

• France fined Google EUR100,000 for not co-operating with the privacy office’s investigation.

• The FTC in the US fined Google US$25,000 after it asked for information five times but got no answer.

• Google then criticised itself by going public with redacted data from the FTC’s report to show that it had known about the collection for years.

• Google wrote to the Australian Privacy Commission to say that the data had been destroyed.

• Google changed its mind and wrote to the Australian Privacy Commission to say that it had found disks on which some of the data remained after all.

• Australia told Google it really, really had to destroy the data this time.

• Google admitted fault to the Information Commissioner’s Office (ICO) in the UK, and got ready to delete the data at last.

• Google paid out $7,000,000, and apologised, to settle a multi-state investigation in the USA.

• The UK ICO found out Google hadn’t deleted all the data, and told Google it really, really had to destroy the data this time.

THE END. BETCHA IT WON’T BE THE LAST OF IT.

Brazil joins in

Indeed, the ICO’s fist-waving wasn’t the last of it.

In the latest phase of the drama, Brazil has joined in with its own demands.

Late last week, Google was given just five days to cough up “detailed information about Google Street View.”

It’s not immediately clear what Google will be expected to reveal, though one imagines that the Brazilians are after as much as they can get.

So Google may well end up handing over information such as: source code; project-related emails from 2007 and beyond; representative samples of collected data; and the details of any previous public investigations already conducted.

→ If Brazil asks for examples of StreetView Wi-Fi data collected back in 2007-2010, there will be a small irony in the assumption that Google has kept that data – and kept it for so long – when its failure to get rid of it in other jurisdictions caused so much trouble for the company.

The penalty if Google doesn’t play ball is a fine of R$100,000 per day (about US$45,000), but the fine only accumulates for ten days, apparently topping out at R$1,000,000 (about US$450,000).

What to do?

Don’t forget that it’s not just Google, but anyone in your vicinity with a Wi-Fi card, who can sniff out your wireless transmissions.

Google, of course, is uniquely placed in respect of the scale of collection it can achieve, and the range of uses to which it can put your data after slurping it up, and that’s why there has been such a long-running outcry over Wi-Spy.

But a data leak is a data leak.

So make sure your own Wi-Fi security is in order today.

Use WPA or WPA2 with a long and hard-to-guess passphrase (you only need to enter it once on each device), and don’t rely on security short-cuts like network name hiding or MAC address filtering.

These short-cuts don’t give you the security you might think, and here’s why:

Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/cElMkUtROx0/

We’ve written about Google’s “Wi-Spy” saga many times before.

And even when we’ve covered a story that suggested that the issue would at last get closure, we’ve said, “Betcha this won’t be the last of it.”

Of course, in just the same way that eventually there isn’t any more toothpaste in the tube, we’ll lose that bet some day.

But not yet, and definitely not this week.

That’s because Google is back in the firing line yet again, years since this all started, this time from Brazil.

The story so far

First, however, here’s the saga so far, or as much as I can remember of it, and not necessarily in chronological order (it all gets a bit hazy after a while).

THE GOOGLE WI-SPY STORY AS A HAIL OF BULLETS, BY P DUCKLIN

• Google’s Street View cars collect Wi-Fi access point information in bulk for geolocation purposes. (Home and business access points tend to stay put, with the same name, for months or years.)

• In 2010, it emerged that for the several years, Google had been sucking up your Wi-Fi payload data at the same time as locating your access point.

• Some Privacy Commissioners decided they didn’t like this and ordered Google to destroy the data at once to prevent its abuse.

• Some Privacy Commissioners decided they didn’t like this and ordered Google to retain the data for investigative purposes.

• Google denied it had collected payload data.

• Google changed its mind and decided that it had collected payload data.

• Australia dubbed it the “single greatest breach in the history of privacy,” but ironically found that local laws didn’t allow any action against Google.

• France fined Google EUR100,000 for not co-operating with the privacy office’s investigation.

• The FTC in the US fined Google US$25,000 after it asked for information five times but got no answer.

• Google then criticised itself by going public with redacted data from the FTC’s report to show that it had known about the collection for years.

• Google wrote to the Australian Privacy Commission to say that the data had been destroyed.

• Google changed its mind and wrote to the Australian Privacy Commission to say that it had found disks on which some of the data remained after all.

• Australia told Google it really, really had to destroy the data this time.

• Google admitted fault to the Information Commissioner’s Office (ICO) in the UK, and got ready to delete the data at last.

• Google paid out $7,000,000, and apologised, to settle a multi-state investigation in the USA.

• The UK ICO found out Google hadn’t deleted all the data, and told Google it really, really had to destroy the data this time.

THE END. BETCHA IT WON’T BE THE LAST OF IT.

Brazil joins in

Indeed, the ICO’s fist-waving wasn’t the last of it.

In the latest phase of the drama, Brazil has joined in with its own demands.

Late last week, Google was given just five days to cough up “detailed information about Google Street View.”

It’s not immediately clear what Google will be expected to reveal, though one imagines that the Brazilians are after as much as they can get.

So Google may well end up handing over information such as: source code; project-related emails from 2007 and beyond; representative samples of collected data; and the details of any previous public investigations already conducted.

→ If Brazil asks for examples of StreetView Wi-Fi data collected back in 2007-2010, there will be a small irony in the assumption that Google has kept that data – and kept it for so long – when its failure to get rid of it in other jurisdictions caused so much trouble for the company.

The penalty if Google doesn’t play ball is a fine of R$100,000 per day (about US$45,000), but the fine only accumulates for ten days, apparently topping out at R$1,000,000 (about US$450,000).

What to do?

Don’t forget that it’s not just Google, but anyone in your vicinity with a Wi-Fi card, who can sniff out your wireless transmissions.

Google, of course, is uniquely placed in respect of the scale of collection it can achieve, and the range of uses to which it can put your data after slurping it up, and that’s why there has been such a long-running outcry over Wi-Spy.

But a data leak is a data leak.

So make sure your own Wi-Fi security is in order today.

Use WPA or WPA2 with a long and hard-to-guess passphrase (you only need to enter it once on each device), and don’t rely on security short-cuts like network name hiding or MAC address filtering.

These short-cuts don’t give you the security you might think, and here’s why:

Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/cElMkUtROx0/

We’ve written about Google’s “Wi-Spy” saga many times before.

And even when we’ve covered a story that suggested that the issue would at last get closure, we’ve said, “Betcha this won’t be the last of it.”

Of course, in just the same way that eventually there isn’t any more toothpaste in the tube, we’ll lose that bet some day.

But not yet, and definitely not this week.

That’s because Google is back in the firing line yet again, years since this all started, this time from Brazil.

The story so far

First, however, here’s the saga so far, or as much as I can remember of it, and not necessarily in chronological order (it all gets a bit hazy after a while).

THE GOOGLE WI-SPY STORY AS A HAIL OF BULLETS, BY P DUCKLIN

• Google’s Street View cars collect Wi-Fi access point information in bulk for geolocation purposes. (Home and business access points tend to stay put, with the same name, for months or years.)

• In 2010, it emerged that for the several years, Google had been sucking up your Wi-Fi payload data at the same time as locating your access point.

• Some Privacy Commissioners decided they didn’t like this and ordered Google to destroy the data at once to prevent its abuse.

• Some Privacy Commissioners decided they didn’t like this and ordered Google to retain the data for investigative purposes.

• Google denied it had collected payload data.

• Google changed its mind and decided that it had collected payload data.

• Australia dubbed it the “single greatest breach in the history of privacy,” but ironically found that local laws didn’t allow any action against Google.

• France fined Google EUR100,000 for not co-operating with the privacy office’s investigation.

• The FTC in the US fined Google US$25,000 after it asked for information five times but got no answer.

• Google then criticised itself by going public with redacted data from the FTC’s report to show that it had known about the collection for years.

• Google wrote to the Australian Privacy Commission to say that the data had been destroyed.

• Google changed its mind and wrote to the Australian Privacy Commission to say that it had found disks on which some of the data remained after all.

• Australia told Google it really, really had to destroy the data this time.

• Google admitted fault to the Information Commissioner’s Office (ICO) in the UK, and got ready to delete the data at last.

• Google paid out $7,000,000, and apologised, to settle a multi-state investigation in the USA.

• The UK ICO found out Google hadn’t deleted all the data, and told Google it really, really had to destroy the data this time.

THE END. BETCHA IT WON’T BE THE LAST OF IT.

Brazil joins in

Indeed, the ICO’s fist-waving wasn’t the last of it.

In the latest phase of the drama, Brazil has joined in with its own demands.

Late last week, Google was given just five days to cough up “detailed information about Google Street View.”

It’s not immediately clear what Google will be expected to reveal, though one imagines that the Brazilians are after as much as they can get.

So Google may well end up handing over information such as: source code; project-related emails from 2007 and beyond; representative samples of collected data; and the details of any previous public investigations already conducted.

→ If Brazil asks for examples of StreetView Wi-Fi data collected back in 2007-2010, there will be a small irony in the assumption that Google has kept that data – and kept it for so long – when its failure to get rid of it in other jurisdictions caused so much trouble for the company.

The penalty if Google doesn’t play ball is a fine of R$100,000 per day (about US$45,000), but the fine only accumulates for ten days, apparently topping out at R$1,000,000 (about US$450,000).

What to do?

Don’t forget that it’s not just Google, but anyone in your vicinity with a Wi-Fi card, who can sniff out your wireless transmissions.

Google, of course, is uniquely placed in respect of the scale of collection it can achieve, and the range of uses to which it can put your data after slurping it up, and that’s why there has been such a long-running outcry over Wi-Spy.

But a data leak is a data leak.

So make sure your own Wi-Fi security is in order today.

Use WPA or WPA2 with a long and hard-to-guess passphrase (you only need to enter it once on each device), and don’t rely on security short-cuts like network name hiding or MAC address filtering.

These short-cuts don’t give you the security you might think, and here’s why:

Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/cElMkUtROx0/

We’ve written about Google’s “Wi-Spy” saga many times before.

And even when we’ve covered a story that suggested that the issue would at last get closure, we’ve said, “Betcha this won’t be the last of it.”

Of course, in just the same way that eventually there isn’t any more toothpaste in the tube, we’ll lose that bet some day.

But not yet, and definitely not this week.

That’s because Google is back in the firing line yet again, years since this all started, this time from Brazil.

The story so far

First, however, here’s the saga so far, or as much as I can remember of it, and not necessarily in chronological order (it all gets a bit hazy after a while).

THE GOOGLE WI-SPY STORY AS A HAIL OF BULLETS, BY P DUCKLIN

• Google’s Street View cars collect Wi-Fi access point information in bulk for geolocation purposes. (Home and business access points tend to stay put, with the same name, for months or years.)

• In 2010, it emerged that for the several years, Google had been sucking up your Wi-Fi payload data at the same time as locating your access point.

• Some Privacy Commissioners decided they didn’t like this and ordered Google to destroy the data at once to prevent its abuse.

• Some Privacy Commissioners decided they didn’t like this and ordered Google to retain the data for investigative purposes.

• Google denied it had collected payload data.

• Google changed its mind and decided that it had collected payload data.

• Australia dubbed it the “single greatest breach in the history of privacy,” but ironically found that local laws didn’t allow any action against Google.

• France fined Google EUR100,000 for not co-operating with the privacy office’s investigation.

• The FTC in the US fined Google US$25,000 after it asked for information five times but got no answer.

• Google then criticised itself by going public with redacted data from the FTC’s report to show that it had known about the collection for years.

• Google wrote to the Australian Privacy Commission to say that the data had been destroyed.

• Google changed its mind and wrote to the Australian Privacy Commission to say that it had found disks on which some of the data remained after all.

• Australia told Google it really, really had to destroy the data this time.

• Google admitted fault to the Information Commissioner’s Office (ICO) in the UK, and got ready to delete the data at last.

• Google paid out $7,000,000, and apologised, to settle a multi-state investigation in the USA.

• The UK ICO found out Google hadn’t deleted all the data, and told Google it really, really had to destroy the data this time.

THE END. BETCHA IT WON’T BE THE LAST OF IT.

Brazil joins in

Indeed, the ICO’s fist-waving wasn’t the last of it.

In the latest phase of the drama, Brazil has joined in with its own demands.

Late last week, Google was given just five days to cough up “detailed information about Google Street View.”

It’s not immediately clear what Google will be expected to reveal, though one imagines that the Brazilians are after as much as they can get.

So Google may well end up handing over information such as: source code; project-related emails from 2007 and beyond; representative samples of collected data; and the details of any previous public investigations already conducted.

→ If Brazil asks for examples of StreetView Wi-Fi data collected back in 2007-2010, there will be a small irony in the assumption that Google has kept that data – and kept it for so long – when its failure to get rid of it in other jurisdictions caused so much trouble for the company.

The penalty if Google doesn’t play ball is a fine of R$100,000 per day (about US$45,000), but the fine only accumulates for ten days, apparently topping out at R$1,000,000 (about US$450,000).

What to do?

Don’t forget that it’s not just Google, but anyone in your vicinity with a Wi-Fi card, who can sniff out your wireless transmissions.

Google, of course, is uniquely placed in respect of the scale of collection it can achieve, and the range of uses to which it can put your data after slurping it up, and that’s why there has been such a long-running outcry over Wi-Spy.

But a data leak is a data leak.

So make sure your own Wi-Fi security is in order today.

Use WPA or WPA2 with a long and hard-to-guess passphrase (you only need to enter it once on each device), and don’t rely on security short-cuts like network name hiding or MAC address filtering.

These short-cuts don’t give you the security you might think, and here’s why:

Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/cElMkUtROx0/

We’ve written about Google’s “Wi-Spy” saga many times before.

And even when we’ve covered a story that suggested that the issue would at last get closure, we’ve said, “Betcha this won’t be the last of it.”

Of course, in just the same way that eventually there isn’t any more toothpaste in the tube, we’ll lose that bet some day.

But not yet, and definitely not this week.

That’s because Google is back in the firing line yet again, years since this all started, this time from Brazil.

The story so far

First, however, here’s the saga so far, or as much as I can remember of it, and not necessarily in chronological order (it all gets a bit hazy after a while).

THE GOOGLE WI-SPY STORY AS A HAIL OF BULLETS, BY P DUCKLIN

• Google’s Street View cars collect Wi-Fi access point information in bulk for geolocation purposes. (Home and business access points tend to stay put, with the same name, for months or years.)

• In 2010, it emerged that for the several years, Google had been sucking up your Wi-Fi payload data at the same time as locating your access point.

• Some Privacy Commissioners decided they didn’t like this and ordered Google to destroy the data at once to prevent its abuse.

• Some Privacy Commissioners decided they didn’t like this and ordered Google to retain the data for investigative purposes.

• Google denied it had collected payload data.

• Google changed its mind and decided that it had collected payload data.

• Australia dubbed it the “single greatest breach in the history of privacy,” but ironically found that local laws didn’t allow any action against Google.

• France fined Google EUR100,000 for not co-operating with the privacy office’s investigation.

• The FTC in the US fined Google US$25,000 after it asked for information five times but got no answer.

• Google then criticised itself by going public with redacted data from the FTC’s report to show that it had known about the collection for years.

• Google wrote to the Australian Privacy Commission to say that the data had been destroyed.

• Google changed its mind and wrote to the Australian Privacy Commission to say that it had found disks on which some of the data remained after all.

• Australia told Google it really, really had to destroy the data this time.

• Google admitted fault to the Information Commissioner’s Office (ICO) in the UK, and got ready to delete the data at last.

• Google paid out $7,000,000, and apologised, to settle a multi-state investigation in the USA.

• The UK ICO found out Google hadn’t deleted all the data, and told Google it really, really had to destroy the data this time.

THE END. BETCHA IT WON’T BE THE LAST OF IT.

Brazil joins in

Indeed, the ICO’s fist-waving wasn’t the last of it.

In the latest phase of the drama, Brazil has joined in with its own demands.

Late last week, Google was given just five days to cough up “detailed information about Google Street View.”

It’s not immediately clear what Google will be expected to reveal, though one imagines that the Brazilians are after as much as they can get.

So Google may well end up handing over information such as: source code; project-related emails from 2007 and beyond; representative samples of collected data; and the details of any previous public investigations already conducted.

→ If Brazil asks for examples of StreetView Wi-Fi data collected back in 2007-2010, there will be a small irony in the assumption that Google has kept that data – and kept it for so long – when its failure to get rid of it in other jurisdictions caused so much trouble for the company.

The penalty if Google doesn’t play ball is a fine of R$100,000 per day (about US$45,000), but the fine only accumulates for ten days, apparently topping out at R$1,000,000 (about US$450,000).

What to do?

Don’t forget that it’s not just Google, but anyone in your vicinity with a Wi-Fi card, who can sniff out your wireless transmissions.

Google, of course, is uniquely placed in respect of the scale of collection it can achieve, and the range of uses to which it can put your data after slurping it up, and that’s why there has been such a long-running outcry over Wi-Spy.

But a data leak is a data leak.

So make sure your own Wi-Fi security is in order today.

Use WPA or WPA2 with a long and hard-to-guess passphrase (you only need to enter it once on each device), and don’t rely on security short-cuts like network name hiding or MAC address filtering.

These short-cuts don’t give you the security you might think, and here’s why:

Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/cElMkUtROx0/

We’ve written about Google’s “Wi-Spy” saga many times before.

And even when we’ve covered a story that suggested that the issue would at last get closure, we’ve said, “Betcha this won’t be the last of it.”

Of course, in just the same way that eventually there isn’t any more toothpaste in the tube, we’ll lose that bet some day.

But not yet, and definitely not this week.

That’s because Google is back in the firing line yet again, years since this all started, this time from Brazil.

The story so far

First, however, here’s the saga so far, or as much as I can remember of it, and not necessarily in chronological order (it all gets a bit hazy after a while).

THE GOOGLE WI-SPY STORY AS A HAIL OF BULLETS, BY P DUCKLIN

• Google’s Street View cars collect Wi-Fi access point information in bulk for geolocation purposes. (Home and business access points tend to stay put, with the same name, for months or years.)

• In 2010, it emerged that for the several years, Google had been sucking up your Wi-Fi payload data at the same time as locating your access point.

• Some Privacy Commissioners decided they didn’t like this and ordered Google to destroy the data at once to prevent its abuse.

• Some Privacy Commissioners decided they didn’t like this and ordered Google to retain the data for investigative purposes.

• Google denied it had collected payload data.

• Google changed its mind and decided that it had collected payload data.

• Australia dubbed it the “single greatest breach in the history of privacy,” but ironically found that local laws didn’t allow any action against Google.

• France fined Google EUR100,000 for not co-operating with the privacy office’s investigation.

• The FTC in the US fined Google US$25,000 after it asked for information five times but got no answer.

• Google then criticised itself by going public with redacted data from the FTC’s report to show that it had known about the collection for years.

• Google wrote to the Australian Privacy Commission to say that the data had been destroyed.

• Google changed its mind and wrote to the Australian Privacy Commission to say that it had found disks on which some of the data remained after all.

• Australia told Google it really, really had to destroy the data this time.

• Google admitted fault to the Information Commissioner’s Office (ICO) in the UK, and got ready to delete the data at last.

• Google paid out $7,000,000, and apologised, to settle a multi-state investigation in the USA.

• The UK ICO found out Google hadn’t deleted all the data, and told Google it really, really had to destroy the data this time.

THE END. BETCHA IT WON’T BE THE LAST OF IT.

Brazil joins in

Indeed, the ICO’s fist-waving wasn’t the last of it.

In the latest phase of the drama, Brazil has joined in with its own demands.

Late last week, Google was given just five days to cough up “detailed information about Google Street View.”

It’s not immediately clear what Google will be expected to reveal, though one imagines that the Brazilians are after as much as they can get.

So Google may well end up handing over information such as: source code; project-related emails from 2007 and beyond; representative samples of collected data; and the details of any previous public investigations already conducted.

→ If Brazil asks for examples of StreetView Wi-Fi data collected back in 2007-2010, there will be a small irony in the assumption that Google has kept that data – and kept it for so long – when its failure to get rid of it in other jurisdictions caused so much trouble for the company.

The penalty if Google doesn’t play ball is a fine of R$100,000 per day (about US$45,000), but the fine only accumulates for ten days, apparently topping out at R$1,000,000 (about US$450,000).

What to do?

Don’t forget that it’s not just Google, but anyone in your vicinity with a Wi-Fi card, who can sniff out your wireless transmissions.

Google, of course, is uniquely placed in respect of the scale of collection it can achieve, and the range of uses to which it can put your data after slurping it up, and that’s why there has been such a long-running outcry over Wi-Spy.

But a data leak is a data leak.

So make sure your own Wi-Fi security is in order today.

Use WPA or WPA2 with a long and hard-to-guess passphrase (you only need to enter it once on each device), and don’t rely on security short-cuts like network name hiding or MAC address filtering.

These short-cuts don’t give you the security you might think, and here’s why:

Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/cElMkUtROx0/