Days of Our Stolen Identity: The Equifax Soap Opera

October 26, 2017 | Leave a Comment

By Kate Donofrio, Senior Associate, Schellman & Co.

The Equifax saga continues like a soap opera, Days of Our Stolen Identity.  Every time it appears the Equifax drama is ending, a new report surfaces confirming additional security issues.

On Thursday, September 12, NPR reported that Equifax took down their website this time based on an issue with fraudulent Adobe Flash update popups on their site, initially discovered by an independent security analyst, Randy Abrams.[1]  Did the latest vulnerability mean Equifax continued with their inadequate information technology and security practices, even after being breached?  Or is it an even worse possibility, that their machines were not completely remediated from the original breach?

As it turns out, Equifax claimed they were not directly breached again, rather one of their third-party service providers responsible for uploading web content to Equifax site for analytics and monitoring was at fault.  According to Equifax, the unnamed third-party service provider uploaded the malicious code to their site.  It appears the only thing Equifax has been consistently good at is placing blame and pointing a finger in other directions.

Equifax needs to take responsibility after all they hired the service provider, are responsible for validating compliance of their service provider’s actions within their environment, and still hold the overall responsibility of their information.  This is a huge lesson for any company who attempts to pass blame to a third-party.

For those that have not been keeping track, below demonstrates a rough timeline of the recent Equifax scandal:

  • Mid-May 2017 – July 29, 2017: Reported period where Equifax’s systems were breached and data compromised.
  • July 29, 2017: Equifax identified the breach internally.
  • August 1 and August 2, 2017: Executives dumped $1.78 million worth of Equifax stock: Chief Financial Officer, John Gamble ($946,374); U.S. Information Solutions President, Joseph Loughran ($584,099); and Workforce Solutions President, Rodolfo Ploder ($250,458).[2]
  • September 7, 2017: Equifax released a public statement about the breach of over 145 million U.S. consumers’ information, 209,000 credit cards, and other breaches of non-US citizen information.[3]
  • September 12, 2017: Alex Holden, founder of Milwaukee, Wisconsin-based Hold Security LLC, contacted noted cybersecurity reporter, Brian Krebs, on a discovered security flaw within Equifax’s publicly available employee portal in Argentina. The Equifax portal had an active administrative user with the User ID “admin” and the password set to “admin.”  For those of you who may be unaware, the admin/admin username and password combination is regularly used as a vendor default, and often a combination tried by users to break into systems.  The administrative access allowed maintenance of users within the portal, including the ability to show employee passwords in clear-text. [4]
  • September 14, 2017: On his blog, Krebs on Security, Brian Krebs posted an article referencing a non-public announcement Visa and MasterCard sent to banks, which stated that the “window of exposure for the [Equifax] breach was actually November 10, 2016 through July 6, 2017.”[5] (Note: Equifax still claims the breach was one big download of data in Mid-May 2017, and that the November dates were merely transaction dates.)
  • September 15, 2017: Visa and MasterCard updated the breach notification to include social security numbers and addresses. [6] They found that the breach occurred on the Equifax’s site where people signed up for credit monitoring.
  • September 15, 2017: Equifax Chief Information Officer, David Webb, and Chief Security Officer, Susan Mauldin retired, effective immediately.[7][8]
  • September 19, 2017: Equifax admitted they tweeted out a bogus website address at least seven times; for instance, promoting “securityequifax2017.com” instead of the correct site, “equifaxsecurity2017.com,” and thus sent customers to the wrong site. Software engineer Nick Sweeting took the opportunity to teach Equifax a lesson and created an identical site at the incorrect “securityequifax2017.com” with a scathing indictment banner at the top of the page: “Why did Equifax use a domain that’s so easily impersonated by phishing sites?”[9]
  • September 29, 2017: CEO, Richard F. Smith stepped down, though he was expected to walk away with roughly $90 million.[10]
  • September 29, 2017: Astonishingly, the Internal Revenue Service (IRS) awarded Equifax a sole source contract (not publicly bid) for roughly $7.25 million to perform identity verifications for taxpayers.[11] Just in case you were not lucky enough to be a part of the recent Equifax breach, the IRS is giving you another “opportunity.”
  • October 3, 2017: During testimony with House Energy and Commerce Committee, former Equifax CEO, Richard F. Smith, blamed one person in his IT department for not patching the Apache Struts vulnerability and for the entire breach.[12]
  • October 10, 2017: Krebs on Security reported the number of UK Residents hacked was 693,665, not the initial 400,000 disclosed.[13]
  • October 12, 2017: Malicious Adobe Flash code was found on Equifax’s website. Equifax blamed a third-party service provider for feeding the information to the site.
  • October 12, 2017: IRS temporarily suspended Equifax’s contract over additional security concerns.[14]

This is not the first time Equifax has been involved in a breach of customer information.  On September 8, 2017, Forbes released an article detailing prior breaches, including one in May 2016 that leaked personal information of 430,000 records of grocer Kroger’s employees[15]from an Equifax site that provided employees with W2 information.  That breach was attributed to attackers determining PIN numbers utilized for site access to break into accounts and steal information.  PIN numbers consisted of the last four digits of an employee’s social security number and their four-digit birth year.

More information keeps surfacing as Equifax continues to simultaneously be scrutinized for their every move and targeted by security personnel and hackers alike.  A huge question remains how a company managing the information of so many people, who was certified compliant under several different certifications, including PCI DSS, SOC 2 Type II, FISMA, ISO/IEC 27001:2013[16] to name a few, could be so negligent.

From my experience, there are a lot of large corporations out there with the mentality that they are just too big to fail or to comply one-hundred percent.  I have heard echoing of this mantra repeatedly over the years, and every time, it makes you want to scream “you are too big not to comply!”

However, history has proven, a lot of these big corporations are in fact too big to fail.  Sure, Equifax is going to be continuously under scrutiny, fined, sued, and have their name dragged through the mud.  However, at the end of the day, they will still be managing the information for millions of people, not just Americans, and business will continue as usual.  They will be the butt of jokes and the subject of discussion for a while, but then the stories will start to fall behind other major headlines and soon all will be forgotten.

The reality is the Equifax saga is nothing new to consumers, and Equifax joins the likes of Target, Home Depot, Citibank, and many other companies who had their name plastered within headlines for major data breaches.

The compromises made some consumers think twice about using these companies, or using a credit card at their locations, but time moves on and eventually convenience always beats security.  Each of the companies compromised took a financial hit at the time, but years later they are still chugging away, some with record profits.  Sure, the damage made them reorganize and rethink security going forward, but why is it that consumers must suffer first before these large companies take steps to protect them?  While millions of consumers could be facing identity theft or financial compromise due to the Equifax breach, Equifax’s executives cashed out large amounts of stock, took their resignation, and will move on to the next company or retire off their riches.

What is the big picture here?  Is it true what Equifax’s ex-CEO said on the stand, that one member of their information security team caused this huge compromise of data? Of course not, and by the way it was ludicrous for a CEO to place blame on one member of their IT staff.  The truth is companies attempt to juggle their personal profit with the company’s security.  Let’s be honest, most of the time information security spends revenue without a return.  The only time a return is realized is when a company mitigates a breach and that information is not often relayed across an organization.

The damages incurred by consumers and even other businesses due to data breaches far outweigh the penalties the negligent companies face.  The Federal Trade Commission claims that recovering from an identity breach averages six months and 200 hours of work[17].  If only 10% of those involved in the Equifax breach have their identities compromised, using average U.S. hourly earnings, that would equate to roughly $77 billion in potential costs to the American people (14,500,000 people * 200 hours * $26.55 = ~$77 billion).  These are just averages and there are horror stories detailing people fighting for years to clear up their identity.

Overall, there needs to be more accountability and transparency in what these corporations are doing with consumer data.  Most of these companies are going through endless audits covering different regulations and compliances, yet it does not seem to matter, as breaches continue to rise in number.

As other countries are progressively moving forward with reforms for the protection of personal information of their residents, such as the European Union’s General Data Protection Regulation (GDPR), the US continues to blindly stumble along, refusing to take a serious look at these issues.  The amount of money these companies are profiting off the data they collect is ridiculous, and when they have a breach, the fines and other punishments are a joke.

It’s time for things to change, as no company should be able to just say, “whoops, sorry about that” after a breach and move on.

What’s New with the Treacherous 12?

October 20, 2017 | Leave a Comment

By the CSA Top Threats Working Group

In 2016, the CSA Top Threats Working Group published the Treacherous 12: Top Threats to Cloud Computing, which expounds on 12 categories of security issues that are relevant to cloud environments. The 12 security issues were determined by a survey of 271 respondents.

Following the publication of that document, the group has continued to track the cloud security landscape for incidents. This activity culminated in the creation of an update titled Top Threats to Cloud Computing Plus: Industry Insights.

The update serves as a validation of the relevance of security issues discussed in the earlier document, as well as provides references and overviews of these incidents. In total, 21 anecdotes and examples are featured in the document.

The references and overview of each anecdote and example are written with the help of publicly available information.

The Top Threats Working Group hopes that shedding light on recent anecdotes and examples related to the 12 security issues will provide readers with relevant context that is current and in-line with the security landscape.

 

CSA Releases Minor Update to CCM, CAIQ

October 19, 2017 | Leave a Comment

By the CSA Research Team

The Cloud Security Alliance has released a minor update for the Cloud Control Matrix (CCM) and the Consensus Assessment Initiative Questionnaire (CAIQ) v3.0.1. This update incorporates mappings to Shared Assessments 2017 Agreed Upon Procedures (AUP), PCI DSS v3.2, CIS-AWS-Foundation v1.1, HITRUST CSF v8.1, NZISM v2.5.

The Cloud Security Alliance would like to thank the following individuals and organizations for their contributions to this minor update of the CCM.

Shared Assessments 2017 AUP
Angela Dogan
The Shared Assessments Team

PCI DSS v3.2 
Michael Fasere
Capital One

NZISM v2.5
Phillip Cutforth
New Zealand Government CIO

HITRUST CSF v8.1
CSA CCM Working Group

CIS-AWS-Foundations
Jon-Michael Brook

Learn more about this minor update to the CCM. Please feel free to contact us at [email protected]nce.org if you have any queries regarding the update.

If you are interested in participating in future CCM Working Group activities, please feel free to sign up for the working group.

The GDPR and Personal Data…HELP!

October 4, 2017 | Leave a Comment

By Chris Lippert, Senior Associate, Schellman & Co.

With the General Data Protection Regulation (GDPR) becoming effective May 25, 2018, organizations (or rather, organisations) seem to be stressing a bit. Most we speak with are asking, “where do we even start?” or “what is included as personal data under the GDPR?” It is safe to say that these are exactly the questions organizations should be asking, but to know where to start, organizations first need to understand how the GDPR applies to their organization within this new definition for personal data. Without first understanding what to look for, an organization cannot begin to perform data discovery and data mapping exercises, review data management practices and prepare the organization for compliance with the GDPR.

Personal data redefined…sort of.
To start – is personal data redefined by the GDPR? Yes. Is it more encompassing of a definition? Yes. Does it provide a good amount of guidance on interpretation of said definition? In some areas, but not in others.

The Articles of the GDPR open with a list of definitions in Article 4 that provide some guidance on how to digest the remainder of the regulation—the recitals also contain some nuggets of wisdom if you have time to review. Personal data is the very first definition listed under Article 4, hinting that it is most likely pertinent to a comprehensive understanding of the regulation. Article 4(1) states:

‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.

In breaking down this definition, there are a few key phrases to focus on. Any information is the big one, as it confirms that personal data, under this regulation, is not limited to a particular group or type of data. Relating to specifies that personal data can encompass any group or type of data, as long as the data is tied to or related to something else. What is that something else? A natural person. A natural person is just that—an actual human being to whom the data applies.

You may have noticed I skipped the ‘an identified or identifiable’ portion of the definition—identified or identifiable means that the natural person has either already been identified, or can readily be identified utilizing other available information. Article 4(1) adds further clarity here, stating that an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person. The fact that name, identification number, location data and online identifier are specifically referenced at the beginning of this definition is important, as those pieces of data serve to directly identify an individual. If that specific data is held by the organization, all related data is in scope.

However, if those unique identifiers are not held, your organization should reference the list of other data that could otherwise identify the natural person and bring everything into scope. For example, you may not have John Smith’s name in your database, but you may have salary, company name, and city that that point directly to John Smith when linked together.

In addition to the new definition of personal data, the GDPR also adds some more specificity around what it deems “special categories” of personal data. Article 9 1. states:

processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade-union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation shall be prohibited.

This definition is important, as this states that certain personal data falls into a subcategory that has stricter processing requirements. Although the requirement above states that processing of special categories of personal data is prohibited, it is important to note that there are exceptions to this rule. Organizations should reference Article 9 if they believe special categories of data to be in scope.

So how does this definition differ from previous definitions of personal data?
Even though the GDPR “redefines” personal data, is it really all that different from existing definitions? As a baseline, let’s refer to two of the more commonly used definitions for personal data taken from the GDPR’s predecessor—the Data Protection Directive—and NIST 800-122.

The Data Protection Directive defines personal data in Article 2 (a), which states ‘personal data ‘ shall mean any information relating to an identified or identifiable natural person (‘data subject’); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity. This definition is almost identical to that of the GDPR. The main difference is that the GDPR added additional data that can identify an individual, such as name, location data and online identifier. By adding these into the mix, the GDPR is clarifying where individuals are presumed to be identified, helping organizations understand that the data associated with those identifiers is in scope and covered under the regulation.

Special categories of personal data is also defined under the Data Protection Directive. Article 8 1. states Member States shall prohibit the processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life. The GDPR expanded on this definition as well, now including genetic and biometric data, as well as sexual orientation data to be included in special categories. Essentially, the GDPR has taken the definitions for both personal data and special categories from the Data Protection Directive and provided more clarity, while making them more inclusive at the same time.

Most people probably expect the Data Protection Directive and GDPR to have similar definitions, as they are essentially version 1 and 2 of modern day EU data privacy legislation, respectively. However, when compared to the definition of personal data contained in U.S.-based guidance, we start to see some key differences. As the National Institute of Standards and Technology (NIST) is widely accepted, let’s look at their definition of personal data found in their Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) from 2010.  NIST 800-122, Section 2.1 states PII is – any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.

In breaking down this NIST definition, we see some similarities, in that the NIST definition starts off just as broadly with the phrasing “any information.” In the same vein, the wording “about an individual” speaks to the clarification provided in the GDPR definition as well. That being said, the definition then goes on to add more specifics regarding information that can identify or be linked to an individual, which is where we start to notice some differences. The identifying pieces of information listed in the NIST definition includes name, social security number, date and place of birth, mother’s maiden name or biometric records. The GDPR is a bit more inclusive in its definition, including name, identification number, location data, and online identifier, which covers most of the items from the NIST definition but also adds the online portion as well. While the GDPR doesn’t include the biometric data in the main definition, it does cover physical and genetic information in the other related information listing.

These differences don’t stop there. The NIST definition does go on to provide guidance on other information that could be linked to the individual, but instead of listing out specific data, the definition focuses rather on sectoral categories of data that seem to be derived from the sectoral privacy laws in the United States. The GDPR definition does not follow this pattern, and instead focuses on the different data that can be linked to an individual from a more generic standpoint, listing out the pieces of information that could be tied to an individual in most industries. Also, while the GDPR definition states that one or more of those other data elements can also identify the individual, the NIST definition really brings that other information into scope by saying it can be personal data as long as the individual is identified—though it does not state that the information can also be used to identify an otherwise unidentified individual.

Final Thoughts
With the GDPR’s becoming effective next year, it’s clear that this new definition of personal data expands on the preexisting EU definition of personal data contained in the Data Protection Directive.  Additionally, it adds more specificity to the data that can be used to identify an individual in comparison with leading US personal data definitions.

Why is this so important and relevant to organizations? This new definition of personal data is the most comprehensive definition to date, bringing into scope more information to be considered than any previous definitions in industry regulations or standards. Now, organizations will need to take another look at their previous determination of personal data and reevaluate their data management practices to ensure that the information they hold has been labeled and handled correctly. In fact, information deemed not applicable to past privacy regulations and standards may now become relevant when taking the new definition of personal data into consideration.

Look no further than IP addresses.  Most companies wouldn’t normally lump in IP addresses with personal data, but the now-effective GDPR specifically calls out online identifiers in the definition of personal data. The Court of Justice for the European Union (CJEU) issued its judgement indicating as such in Case C-582/14: Patrick Breyer v Bundesrepublik Deutschland, setting precedent that even dynamic IP addresses can be considered personal data in certain situations. Given this new standard, it will be important for organizations to incorporate judgements from recent cases and guidance from the Article 29 Working Party (being replaced by the European Data Protection Board in May of 2018) when determining how the GDPR impacts to their organization and how best to comply.

New procedures and criteria can be confusing, but hopefully the information above has provided some clarity around this new definition of personal data that the GDPR will introduce next year. Basic knowledge of these definitions can be a starting point for determining how the GDPR applies to your organization, and  if approached from a comprehensive data and risk management standpoint, this information can help better prepare your organization for compliance with the GDPR and other future privacy regulations and frameworks.

If you should have any questions regarding the new definition of personal data or the GDPR in general, please feel free to reach out to your friendly neighborhood privacy team here at Schellman.