OlenderFeldman was interviewed by U.S. News and World Report about when to give out your social security number and how to protect it, so that you can protect your privacy.

Most people get requests for their social security number on a regular basis, and it is often difficult to understand whether you are required to give that information or when it’s purely optional. In a recent U.S. News and World Report article, Aaron Messing provided some tips about determining when that information is required:

“It’s hard to tell whether a business is going to follow best practices,” says Aaron Messing, an information privacy attorney at OlenderFeldman LLP in New Jersey. “The best way to protect private information including Social Security numbers is to limit who has access to it.”

In addition to asking why your social security number is necessary and how it will be used, Aaron recommends offering an alternate identifier, such as a

driver license number, being skeptical of emails and incoming phone calls and not oversharing online:

Don’t over-share online. Until 2011, the Social Security Administration assigned Social Security numbers in a predictable way. “If you share your birthday, age and place of birth, for example, on Facebook, studies have shown that Social Security numbers can be predicted based on publicly available information,” Messing says. “The Social Security Administration started randomly assigning Social Security numbers in June 2011 for that reason.” He recommends never publicly sharing your year of birth and choosing a different year when asked for online forms. “Add or subtract some years, as long as it’s a number you’ll remember,” he says.

Read the whole article here. Aaron was previously quoted regarding privacy and protection of social security numbers for State Farm’s Good Neighbor magazine.

When should you provide your social security number? State Farm asked us when sharing is required.

State Farm contacted OlenderFeldman LLP to ask when sharing your social security number is appropriate:

Think before revealing your Social Security Number (SSN). Its unauthorized use could lead to privacy invasion and identify fraud. Aaron Messing, an information privacy attorney at OlenderFeldman LLP, says sharing is generally required by law only for:

  • Records of financial transactions in which the IRS is interested (banking, stock market, investment, property, insurance or other financial transactions
  • Employment records
  • Driver’s license applications
  • Government benefit applications (Medicade, student loans, etc.)
  • Joining the armed forces
  • Obtaining some professional or recreational licenses

 

You can see the Fast Tracks article here.

Yesterday, the Federal Trade Commission (FTC) announced two proposed settlements of complaints filed against Ceridian Corporation and Lookout Services, Inc.   Both proposed consent orders require the companies to implement security measures similar to other such settlements, including development and implementation of more robust information security programs, along with biennial security assessments and reporting by qualified personnel for 20 years collaboration tools for business.

Ceridian provided payroll services allowing input of sensitive employee information such as social security numbers.  Lookout provided a tool to allow employers to create and track immigration status information for employees which also allowed input and storage of employee sensitive personal information.

Both companies made security representations on their web-pages and/or through customer contracts creating the impression that the companies used industry standard secure technologies and security practices to safeguard their customers’ employee information.

Hackers breached Ceridian’s online perimeter defenses through SQL injection attack, resulting in compromise of the sensitive data.

An employee gained unauthorized access to Lookout’s database by using “predictable resource location” – essentially a brute force attack using educated guessing to reveal hidden files or functionality using common naming conventions in order to by-pass Lookout’s secure log-in page.  In addition, Lookout supposedly allowed a “test” environment to allow access to real data, again enabling the Lookout employee to access sensitive information through logging-in with a “test” username, along with other predictable measures.  Lookout allegedly did not use an intrusion detection system, and did not review logs in a timely manner.

Lookout allegedly made the following claims in marketing materials:

“Although the data is entered via the web, your data will be encoded and transmitted over secured lines to Lookout Services server. This FTP interface will protect your data from interception, as well as, keep the data secure from unauthorized access. Perimeter Defense – Our servers are continuously monitoring attempted network attacks on a 24 x 7 basis, using sophisticated software tools.”

Ceridian allegedly made the following representations on its web-page and in contracts with customers:

“Worry-free Safety & Reliability . . . When managing employee health and payroll data, security is paramount with Ceridian. Our comprehensive security program is designed in accordance with ISO 27000 series standards, industry best practices and federal, state and local regulatory requirements.

Confidentiality and Privacy: [Ceridian] shall use the same degree of care as it uses to protect its own confidential information of like nature, but no less than a reasonable degree of care, to maintain in confidence the confidential information of the [customer].”

Although there are no admissions of liability in the settlements, the alleged liability in Lookout’s situation seems fairly clear.  As alleged, the interface simply did not protect the information, the company did not monitor its network, and sophisticated software tools were seemingly not in use.

The situation for Ceridian is somewhat more troubling.  Its claims and representations focused on the design of its security program, and using “reasonable care.”   The FTC alleged that Ceridian’s practices were not “reasonable.”  Specifically, the Commission alleged that Ceridian: “(1) stored personal information in clear, readable text; (2) created unnecessary risks to personal information by storing it indefinitely on its network without a business need; (3) did not adequately assess the vulnerability of its web applications and network to commonly known or reasonably foreseeable attacks, such as “Structured Query Language” (“SQL”) injection attacks; (4) did not implement readily available, free or low-cost defenses to such attacks; and (5) failed to employ reasonable measures to detect and prevent unauthorized access to personal info! rmation.”

It’s pretty much a given that if a hacker is intent on accessing your network, no amount of security layering will necessarily prevent that unauthorized access.  However, certain things are clear from these cases: companies must assess the sensitivity of the information they hold, and design and implement security programs which correspond to the risk associated with that information.  Even if layers of defense are employed, if you handle sensitive data, assessments of the need for encryption, hashing, truncation, tokenization, limitation and minimization, application and network vulnerability testing, and monitoring of the network systems must be considered and implemented where appropriate.

It is also extremely important to use language that accurately reflects what is supported in policies (public facing and internal), as well as in contracts and privacy and security addenda.  This is not an area to gloss over as an additional exhibit to a master agreement.  The language of privacy and information security addenda or stand-alone contracts, as well as the promises made in marketing materials, SOWs, websites, etc., must be accurate, and should not downplay risks.  In certain cases, more specific contractual obligations are better than broader “reasonable” clauses.  These might clearly define the security requirements to be implemented, and what can be supported.   A corollary to this, particularly in the SaaS service provider context is accurately advising the business customers about disclosures and consents to be made to the users and data subjects whose info! rmation will be processed through the use of the system.

Additionally, merely advising about all risks and disclaiming responsibility for everything is not sufficient, because of the negative effects on business and marketing.  There is also no guarantee that even if there is a broad advice and disclaimer concerning security risk, that the FTC would not seek to use its “harm based” as opposed to “deception based” approach.  That is, “You handle sensitive information under circumstances where the harm may outweigh the benefit; therefore, you have a concomitant responsibility to protect that information.”

Service providers (and others) handling sensitive information must develop, document, manage, and train on their information security architecture.  The risks and obligations spread clearly beyond simple security mechanisms, but to the whole panoply of security layering and defense in depth.