After the Equifax fiasco, how do we move forward?

Heads are starting to roll after the Equifax fiasco, while its PR agency pretends to offer timely communication and churns out CYA updates.  Follow the saga right here. In the Sept. 15 update, Equifax announced its CIO and CSO are retiring, effective immediately.  Uh-huh.

Here is one question of many I would love to ask Equifax execs – why did you wait until Sept. 15 to present a bulleted list of what happened back at the end of July?  I have a host of other non-question questions I want to ask, but let’s take a collective deep breath and learn self control.  Beyond eviscerating  the execs at Equifax, how do we move forward?

Here are some thoughts.

Should everyone freeze their credit?

A few days ago, I would have said yes.  But now, I’m not so sure.  Brian Krebs in his Krebs on Security blog popularized the idea back in 2015 – and it’s a good idea, but there are tradeoffs.  When you freeze your credit, it’s frozen until you un-freeze it. At least, that’s how it’s supposed to work, assuming the CRAs do their jobs. (CRA – Credit Reporting Agency).  If anyone tries to take out a loan in your name, presumably, the lender will check with the CRA, find out your credit is frozen, and turn down the loan.  Which is why you do it.  But if you try to take out a loan, the same thing happens. And now you might have pay to unfreeze it, do your transaction, and then freeze it again, times four CRAs, apparently at $10 or so each.

One of many aspects about this whole breach incident is, if CRAs charge for credit freezes, incompetent behavior turns into a windfall with millions of consumers parting with hard-earned money to freeze their credit with agencies who collected data about us without our consent.  Equifax is offering free credit freezes for a limited time – I’m not sure about the others.

Besides money, the challenge to freezing credit right now is, the CRAs are swamped with freeze requests.  CNN did a video a few days ago of somebody trying to freeze her credit with Equifax.  She tried doing it from that equifaxSecurity2017.com website and it referred her to a toll free phone number. She called the phone number and heard a recorded message to call back during normal business hours – the graphic on the story said she called around 10 am on a weekday.

I wish I could offer an easy answer to all this, but I don’t see one.  Keeping a close eye on bank and credit card transactions is always good, but if somebody uses my Social Security number to borrow a $zillion in my name, I won’t find out about it until it’s already happened.  And then I’m guilty until proven innocent and, at minimum, will spend hours unraveling the mess.

Reality bites sometimes.  Thanks Equifax.

Is the EquifaxSecurity2017 website tool any good?

That tool is… well, it needs improvement.  It’s supposed to make it easy for me to find out if I’m exposed, and then help me sign up for free credit monitoring.  I fed it my SSN with a bogus name last week and it said I may be affected.  I fed it a bogus SSN and name and it said it doesn’t appear that I’m affected.  With either choice, it presented a button to sign up for a free year of credit monitoring.  Oh joy.  Now I can feel secure that the company that let all my horses out of the barn will tell me when somebody steals my horse.

Is one year of Equifax credit monitoring false security?

Yes – false security indeed.  The main problem is, by the time you find out somebody borrowed $zillions in your name, it’s too late.  They’ve already stolen the money and they’re gone, leaving you holding the bag.  Every breach victim company offers credit monitoring because they’re nothing else they can do.  The horses are already out the barn door.  Freezing credit is one way to cope with a broken system, but it’s really just a workaround.

How do we fix the system?

Today’s system is fundamentally broken and something like this was bound to happen sooner or later.  And the bad news is, it’s not over yet.  But today’s broken system, which is bigger than Equifax, does not take Equifax off the hook and the law needs to hold Equifax execs accountable for their negligence.  In fact, since Equifax helped build today’s broken system, Equifax execs are even more culpable.  Heads need to roll.

But there is a solution.  Here are some rough first draft thoughts.

First – who are the stakeholders?  Consumers need access to credit.  Creditors need a way to assess risk and authenticate consumers.  The more efficient this process, the better for society.  That’s why we need CRAs – to match consumers with creditors.  CRAs play an important role.

One problem – consumers are CRA raw material and not CRA customers.  So CRAs have no incentive to care about the confidentiality, integrity, and availability of consumer data. Which means consumers have no power and no recourse when CRAs fail in their duty.

Another problem – CRAs adopted SSNs for authentication because every American has one, and that started a ticking time-bomb because SSNs never change.  The bomb went off years ago when many SSNs became public.  The public found out about it last week when 143 million of us were exposed.  When I provide an SSN, I don’t prove I’m me, I only prove I know the SSN that belongs to Daniel Gregory Scott.  Same for my driver’s license number, date of birth, mother’s maiden name, and anything else I might know that’s public knowledge.  The shorthand way to say this is, my SSN identifies me, but does not authenticate me.

A private passphrase could authenticate me.  Not a password, but a passphrase.  Passphrases are more secure than passwords because they have more characters and they’re easier to remember than passwords filled with random characters.  The passphrase, “Your mom wears army boots” is more secure and easier to remember than a password, say, “@rMyb00ts!”

A passphrase also has an advantage that I control it and I can change it any time I want.

So, for starters, let’s encrypt all that data CRAs hold about me with a passphrase I control.  Anyone who wants to look at my data goes through me first.  Which gives me all the advantages of a credit freeze with fewer hassles. Nobody can borrow money in my name, because nobody can check up on me with a CRA unless they know my passphrase.  CRAs don’t know the plaintext contents of my data – they only know the encrypted contents.  I control the key, which means I control the access.

That’s radical surgery.  CRAs will scream about how much work it will require to educate consumers and set all this up.  They’ll also scream because this idea takes away much of their power.

Many consumers will also scream about taking on the responsibility to remember a passphrase. And what happens if a consumer forgets their passphrase?  The easy answer – Banks or other institutions can offer a passphrase storage service.

And creditors will scream about how it complicates the system and makes offering credit more difficult than before.

I plead guilty on all charges.   But we have 143 million reasons to change the system, and either we do it in the private sector or the government will force something down everyone’s throat.  And, as a consumer, I should have control over data about me.  Millions of us should have demanded it 30 years ago.

Longer term, let’s task an industry group with all stakeholders represented to come up with standards for how all this stuff should work, and put it through the gauntlet of peer scrutiny, similarly to how other open standards are designed.  This group doesn’t need legal power, just credibility.  Enough credibility that everyone will listen and follow the standards it sets.

The system today is opaque and broken.  Let’s use this fiasco as an opportunity to open it up and redesign it for everyone’s benefit, including CRAs.

I want to thank Kim Insley with KARE-11 TV in Minneapolis for providing the questions to organize all these thoughts.

What do we know about the Equifax data breach?

I shared my initial thoughts about the Equifax data breach in this post from Sept. 8, 2017.  And here is the recording from my WCCO Radio interview with Jordana Green and Paul Douglas.  What follows is an update as of Sept. 11, 2017.

(As of Sept. 14, 2017, this original post is now obsolete, but I’m leaving it intact to preserve the sequence of when we learned key facts. See the bottom for updates from Sept. 13, and Sept. 14 2017.)

The Equifax data breach announcement came on on Sept. 7, 2017.  As of Sept. 11, we still have few facts.  But we do have a tantalizing blog post from a news outlet named Quartz.  Check out this article.

The Quartz article references a Baird Equity Research report about how the breach will effect Equifax stock.  Here is the report.  This key sentence in the report is at the heart of lots of speculation:

Our understanding is data retained by EFX primarily generated through consumer interactions was breached via the Apache Struts flaw…

Apache Struts is a software framework for building Java applications. Struts has had two vulnerabilities recently. One was reported and patched in March, the other on Sept. 4.

Here is another article about Apache Struts from ZDnet.

And now speculation. The Equifax data breach announcement said the attack exploited a website flaw, but I can find no other details beyond that.  The Baird Equity Research report above is not clear about which Struts vulnerability, and doesn’t cite a source.

A few possible scenarios play out here. In the first scenario, Equifax never applied the patch for the March vulnerability and bad guys romped through its systems for two months undetected. This scenario is Equifax’s fault.

In the second scenario, bad guys discovered the new vulnerability before good guys found it. The patch didn’t come until Sept. 4. Smart bad guys could have easily covered their tracks while romping across the Equifax network, such that no automation looking for suspicious patterns would have uncovered it. Somehow, Equifax found the invasion on July 29. Under this scenario, the long wait for disclosure might make sense because there was no fix available until Sept. 4, and Equifax disclosed the breach Sept. 7.

I find this scenario hard to believe because five weeks – from July 29 until Sept. 4 – is a long time for anyone to fix a reported software vulnerability, especially one already in the wild.  The best open source developers pride themselves on great workmanship, and taking five weeks to patch a security flaw is inconceivable. Here is what the Apache Software Foundation had to say about Apache Struts and Equifax.

And the third scenario puts it right back on Equifax – maybe Apache Struts isn’t relevant, since we don’t know where the Baird Equity Research report got its information.

Let’s not rush to judgement yet because there is one credible scenario where Equifax disclosed this thing properly and is not culpable for the breach. I wrote a blog post about how proper disclosure should work right here.

But if Equifax wants to salvage its credibility, then the people with first-hand knowledge need to share what they know about what happened.

Update Wednesday, Sept. 13, 2017

USA Today reported yesterday that Equifax itself said an Apache Struts vulnerability was the attack vector.  But the article does not tell who from Equifax said it, which is frustrating. Here is the relevant paragraph.

On Tuesday, credit reporting company Equifax told USA TODAY the breach was due to an Apache Struts vulnerability. Apache Struts is free, open-source software used to create Java web applications. Several vulnerabilities have been reported, all since patched, but Equifax has not said which one was involved in this breach.

Update Thursday, Sept. 14, 2017

Equifax blew it.  Heads need to roll.  Scenario one above is what happened.  Equifax failed to patch the March Apache Struts vulnerability and allowed attackers to rampage through its network for two months.

The articles quoting the Equifax update are everywhere.  See this ZDnet article and this Ars Technica article.  Their source is the infamous EquifaxSecurity2017.com site. Click on the Sept. 13, 2017 progress update for consumers.

“The vulnerability was Apache Struts CVE-2017-5638. We continue to work with law enforcement as part of our criminal investigation, and have shared indicators of compromise with law enforcement.”

Let’s summarize.  The people in charge at Equifax learned about the problem on July 29, but didn’t report it until September 7.  A week later, on September 14, after bungling the response they spent five weeks preparing, and only in the face of an uproar, they finally told us which vulnerability the attackers exploited. But they knew all along which vulnerability it was.  Why not report it in the first disclosure?

It gets worse. Three senior executives sold Equifax stock after discovering the breach and before the public announcement. Here’s an extract from this MarketWatch story:

As first reported by Bloomberg NewsChief Financial Officer John Gamble banked $946,374 on the sale, U.S. Information Solutions President Joseph Loughran made $584,099 and Consumer Information Solutions President Rodolfo Ploder earned $250,458. In the same filing, Loughran exercised an option to buy 3,000 shares at a price of $33.60.

Look closely at those titles.  Chief Financial Officer, US Information Solutions President, and Consumer Information Solutions President.  Equifax claims these senior executives had no idea somebody stole the data they were in charge of protecting when they sold their stock.  If true, these folks are incompetent.  If false, they’re crooks.

But wait. There’s more.

Take a look at this Krebs on Security post from Sept. 12.  It’s a story about Equifax operations in Argentina. I’ll quote one key paragraph.

It took almost no time for them to discover that an online portal designed to let Equifax employees in Argentina manage credit report disputes from consumers in that country was wide open, protected by perhaps the most easy-to-guess password combination ever: “admin/admin.”

I’m still shaking my head.

Equifax CEO Richard Smith is expected to testify in front of Congress on Oct. 3.  I would love to be in the room and ask a few questions.

Somebody stole your personal information in the Equifax data breach. Now what?

(I originally posted this on Sept. 8, 2017. Here is an update from a week later.)

Here are a few articles about the Equifax data breach, first reported Sept. 7, 2017.

  • A New York Times article, here.
  • A nice Krebs on Security writeup, here.
  • SC Magazine posted a piece, here.
  • And a ZDnet article, here.

It’s all over the news.  Lots of noise so far, little information.  Here is a bulleted summary of what we know to date.

  • Attackers penetrated Equifax in May, 2017 and gained access to data about 143 million people.
  • Somebody discovered it on July 29, 2017.  Apparently, the attackers took advantage of a web site flaw.  As of Sept. 8, 2017, that’s all the tech details we know.
  • A few Equifax execs sold a bunch of stock around Aug. 1, 2017. Equifax PR people say the execs had no knowledge of the data breach.  Uh-huh.
  • Equifax hired Mandiant, a respected IT forensics firm, to investigate.
  • Equifax set up a website, https://www.equifaxsecurity2017.com, for anyone to look up whether they might be effected.  Feed it a last name and the last six social security number digits.  Note the irony of feeding a social security number to a website for a company that just reported somebody exploited a web site flaw to steal 143 million social security numbers from another company website.
  • Equifax told the world about the intrusion on Sept. 7, 2017.

This latest Equifax breach is a big deal, but the ugly truth is, after years of data breaches, our personal information is already up for sale. And it’s not the first Equifax breach.  Quoting the Krebs on Security article I linked above:

This is hardly the first time Equifax or another major credit bureau has experienced a breach impacting a significant number of Americans. In May, KrebsOnSecurity reported that fraudsters exploited lax security at Equifax’s TALX payroll division, which provides online payroll, HR and tax services.

And Equifax is not the first credit reporting agency to lose our personal information. Take a look at a tangled story about how Equifax competitor, Experian became an unwitting partner in an identity theft ring in the Krebs on Security post right here.  Here’s another article.

You read that word correctly.  I really did say, partner.  Experian unwittingly partnered with an identity theft ring from Vietnam a few years ago after buying a company named Court Ventures back in 2012.

Wonderful – we can’t trust the credit reporting agencies everyone uses to assess our trustworthiness. Now what?  The most workable solution I’ve found is setting up a credit freeze.  Which means paying money to these same credit reporting agencies to set it up and trusting they’ll do their jobs.

Here is a link to another Krebs on Security post with details. Here is a link to the US Federal Trade Commission page about credit freezes. And one more link to a Consumer Reports page about credit freezes, here.

The idea is, pay a fee to each credit reporting agency to flag your record with a freeze notification.  Anyone who wants to open an account in your name will theoretically check with one of these agencies and deny it, since it’s flagged as frozen.  But this is a hassle because if you want to borrow money for, say, a mortgage or a car, you have to spend money to unfreeze your credit with the relevant agency, and then spend more money to freeze it again. Not a bad gig if you’re a credit reporting agency.  A hassle if you’re a consumer, but it might save you from an identity thief.

Also, be on the lookout for emails claiming to come from Equifax with “click here” links claiming to set you up for free credit monitoring for a year.  As of this writing, I know of no such emails, but it’s inevitable some senior manager at Equifax who doesn’t know better will want to send one. It’s part of the typical pattern. Check your email header to make sure any email claiming to come from Equifax really does come from Equifax, and make sure the “click here” link really does point where it claims to point.  See my post about How to Spot a Phishy email for more.

I’ll update this post as new information becomes available.

Finally, keep an eye on my dgregscott.com website for resources.  I have a bunch of mini-seminars and blog posts with how-to information, and you’re welcome to all of it, no strings attached.  And if you like what I put together, I’d appreciate it if you would consider buying a copy of one of my books.  Here is a link for more book information.

 

What to do when your Internet doesn’t work

Internet trouble can make you crazy. You’re posting away on Facebook and suddenly your posts don’t post anymore.  Or maybe you’re emailing your sister and your email program complains it can’t connect to the server. Or maybe your fancy smartTV won’t connect to Netflix.

Now what?

Of course, you call for help.  But whom do you call?  And what do you tell the tech support specialist when they answer after you’ve waited on hold for who-knows-how-long?

Here is a quick diagnostic for anyone who suspects overall Internet trouble. Do this first, before you call, and you might save yourself and your telephone support technician hours of frustration.

But a caution – this means getting your hands dirty with technology.  If that scares you, get over it, for your own good. None of this is rocket science.

One more caution. None of this works with a smartphone or TV. Some smartphones and TVs have primitive diagnostic tools, but as of late summer, 2017, doing this right still requires a real computer.  Or, at minimum, a download into your phone.

This first test takes about 10 seconds. Launch a command line window (how-to details below). Don’t be freaked out that it looks like a 30-year-old step back in time. Inside that window, type this command:

ping www.google.com

and check the results. Here is how it looks from a Windows system when everything works. Macintoshes will behave similarly.

C:\Users\gregs>ping www.google.com

Pinging www.google.com [216.58.216.228] with 32 bytes of data:
 Reply from 216.58.216.228: bytes=32 time=20ms TTL=56
 Reply from 216.58.216.228: bytes=32 time=20ms TTL=56
 Reply from 216.58.216.228: bytes=32 time=20ms TTL=56
 Reply from 216.58.216.228: bytes=32 time=20ms TTL=56

Ping statistics for 216.58.216.228:
 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
 Approximate round trip times in milli-seconds:
 Minimum = 20ms, Maximum = 20ms, Average = 20ms

C:\Users\gregs>

Ping sends a data packet to the destination you specify and waits for an echo reply. Just like the old submarine movies, only this is across the Internet. And it’s software, not real sounds. The idea is, ping a popular destination and watch for the reply to come back. Not everyone answers pings, but Google is kind enough to do so. If Google doesn’t reply reliably, then you probably have an overall Internet problem.

Also, watch the milliseconds – in my case above, it’s consistent at 20ms. That’s the round-trip time for the echo request to go out and the echo reply to come back. If your milliseconds bounce around all over the place, you may have a problem – or your Internet connection might just be busy from other family members streaming who-knows-what.

Here’s how to launch a command line window:

In Windows XP, click Start…Run.  In Windows 7 and 10, just click the Start button. In the box right next to the Start button, type CMD and press the Enter key. There are other ways to do it, but this is the easiest and it’s universal.

In Windows 8 and 8.1, press the Windows and R keys on your keyboard. The Windows key is on the bottom row of your keyboard, right next to the Alt key, on either side of the space bar. In the box, type “CMD” and press Enter.

If you have a Mac, launch the Terminal, found in /Applications/Utilities/

Next Step

Here is your troubleshooting decision tree.

If your pings show something like this:

C:\Users\gregs>ping www.google.com
 Ping request could not find host www.google.com. Please check the name and try again.

C:\Users\gregs>

then you may have an overall connectivity issue, or maybe just a name translation problem. You need another test to be sure. Since we know one IP Address for Google from above, just try to ping that raw IP Address:

ping 216.58.216.228

and see what it reports. If you see 4 replies and the milliseconds look reasonable, raw connectivity is good and you have a name translation problem. If you see errors, you probably have a raw connectivity problem. Do one more command. My example below is from Windows.  For Macintosh, the command will be “traceroute,” spelled out.

racert 216.58.216.228

The tracert command traces the route from you to your destination. It’s kind of like looking at a map to find all the stops on a road trip between Minneapolis and Dallas. Or pick your favorite cities. Here is what it looks like when everything is normal – your hops will be different.

C:\Users\gregs>tracert 216.58.216.228

Tracing route to ord31s22-in-f4.1e100.net [216.58.216.228]
 over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms fw.infrasupport.local [10.10.10.1]
 2 <1 ms <1 ms <1 ms 216.160.2.158
 3 12 ms 10 ms 11 ms stpl-dsl-gw14.stpl.qwest.net [207.109.2.14]
 4 10 ms 11 ms 10 ms stpl-agw1.inet.qwest.net [207.109.3.105]
 5 20 ms 19 ms 20 ms cer-edge-17.inet.qwest.net [67.14.8.90]
 6 21 ms 20 ms 20 ms 216.111.90.126
 7 * * * Request timed out.
 8 20 ms 21 ms 20 ms 209.85.249.73
 9 20 ms 22 ms 21 ms ord31s22-in-f4.1e100.net [216.58.216.228]

Trace complete.

C:\Users\gregs>

Notice one of the intermediate hops in-between Google and me did not respond. That’s normal. Sometimes routers on the Internet don’t answer echo requests. You don’t care about that – you care about whether and where the tracert dies, which means where all the rest of the hops report “Request timed out.”

The tracert will max out at 30 hops, but if you’re in a hurry, press the Ctrl and C keys on your keyboard to abort it.

Total time for all this – maybe 60 seconds.

And now you have something to give your tech support specialist when you call for help. If you talk to anyone beyond a brand-new rookie, they’ll appreciate you for taking these basic troubleshooting steps first and may take your problem reports more seriously than otherwise.