Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

News

9/11/2017
12:30 PM
Jai Vijayan
Jai Vijayan
Slideshows
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

7 Takeaways From The Equifax Data Breach

The exposure of PII belonging to 143 million US consumers raises questions about the continued use of SSNs as identifiers, breach liability and app sec spending.
Previous
1 of 8
Next

(Image Source: Ivelin Radkov via Shutterstock)

(Image Source: Ivelin Radkov via Shutterstock)

Credit bureau Equifax's disclosure last week that unknown intruders had broken into its systems and accessed sensitive data on 143 million US residents has evoked a mixture of resignation, concern, and outrage.

The resignation stemmed from the fact that the breach is identical to countless ones before it. Once again a security hole in a Web application gave intruders a way to break into a major company's systems and siphon out a massive amount of data over more than two months without apparently triggering any alarms. The pattern has become so familiar in recent years that there really are no new lessons to be learned from these breaches anymore, at least from a security preparedness standpoint.

The sheer scope of the Equifax compromise has caused a lot of concern. The breach could well be the largest ever involving the exposure of Social Security Numbers, driver's license numbers, and other personally identifiable information. Victims could be at risk of identity theft and impersonation fraud for the conceivable future.

What has caused the outrage is Equifax's apparent security lapses in allowing a breach of this magnitude to happen. Many feel that Equifax, as a company handling vital PII belonging to a very large swath of the American population should have been especially careful about protecting the data. Instead, it appears to have allowed the breach to happen because of its failure to address an Apache Struts vulnerability that it should have known about and addressed.

A lot has been made about the growing sophistication of threat actors and the arsenal of increasingly deadly cyber tools at their command. The depressing reality, however, is that the bad guys rarely need to deploy anything more than rudimentary tools and techniques. As SentinelOne's chief of security strategy Jeremiah Grossman points out, many breaches can be prevented. "If we review the history of breaches, very few, if any, were the result of an exploit or attack technique that couldn't be seen coming," he says. "With respect to the vulnerabilities exploited, we know everything about them—how to prevent them, detect them and fix them." But people in the best position to make an impact are not incentivized to do so.

Here in no particular order are seven takeaways from the Equifax breach:

 

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio

Previous
1 of 8
Next
Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
mrgorle@yahoo.com
50%
50%
[email protected],
User Rank: Apprentice
9/13/2017 | 9:34:21 AM
Excellent and well written article
Excellent Article Jay.  content and quality of the material is worth spending time eventhough 8 times clicking the clicking the arrow....
lunny
50%
50%
lunny,
User Rank: Strategist
9/20/2017 | 11:55:04 AM
Simplify the Mess
The app vulnerability was just the ingress point.  There are many open windows and unlocked doors that allowed the intruders to move about laterally and vertically throughout the environment.  We'll know more details eventually, as the litigation is sure to push much of the story into the public record.  The intruders got in, hid, obtained privileged credentials, and subsequently enjoyed free reign.  It wasn't hard.

We've got to stop treating servers like pets.  They are cattle.  They should all be standardized and we should build them all at the touch of a button from a single image that is fully patched.  You should be able to do this at any time and in just a few minutes.  It's called orchestration.  We're using orchestration to push out new code, but we are too timid to use it to bake security into the mix.  Despite all of the virtualization and cloud implementatinos, we're still patching servers as if they were all special and physical.  This is insane!  This is why companies cannot realistically patch all of their servers.  They are afraid it will be hard, complex, and things will break.  They're right.  Because every systems administrator, application owner, IT executive, business executive thinks their systems are special.  Well-designed network segmentation and a strong privileged access management regime is critical.

Equifax was simply whistling past the graveyard.  What will be written on their tombstone now?
REISEN1955
50%
50%
REISEN1955,
User Rank: Ninja
9/20/2017 | 1:11:19 PM
New Discoveries
Perhaps I am a broken record, but I am amazed at the NEW IT SECURITY PROTOCOL discoveries that are made after every epic event - Delta, Merck, Equifax.  Such concepts are stunning - wow, like nobody thought of education for your user base (email basics) ----- power backup batteries in the bottom of a 42U server rack and a generator farm outside if needed ..... having on and offsite backups that are tested ---  patching applications and patching operating systems.  And always the management view that IT is just JUST an expense line item, so fire all the techs who know something and farm it all out to outsourcing firms that ONLY care about THEIR INVOICING.  Incredible how we shoot ourselves in the feet every single time. 
Sodinokibi Ransomware: Where Attackers' Money Goes
Kelly Sheridan, Staff Editor, Dark Reading,  10/15/2019
Data Privacy Protections for the Most Vulnerable -- Children
Dimitri Sirota, Founder & CEO of BigID,  10/17/2019
State of SMB Insecurity by the Numbers
Ericka Chickowski, Contributing Writer,  10/17/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-17424
PUBLISHED: 2019-10-22
A stack-based buffer overflow in the processPrivilage() function in IOS/process-general.c in nipper-ng 0.11.10 allows remote attackers (serving firewall configuration files) to achieve Remote Code Execution or Denial Of Service via a crafted file.
CVE-2019-16404
PUBLISHED: 2019-10-21
Authenticated SQL Injection in interface/forms/eye_mag/js/eye_base.php in OpenEMR through 5.0.2 allows a user to extract arbitrary data from the openemr database via a non-parameterized INSERT INTO statement, as demonstrated by the providerID parameter.
CVE-2019-17400
PUBLISHED: 2019-10-21
The unoconv package before 0.9 mishandles untrusted pathnames, leading to SSRF and local file inclusion.
CVE-2019-17498
PUBLISHED: 2019-10-21
In libssh2 v1.9.0 and earlier versions, the SSH_MSG_DISCONNECT logic in packet.c has an integer overflow in a bounds check, enabling an attacker to specify an arbitrary (out-of-bounds) offset for a subsequent memory read. A crafted SSH server may be able to disclose sensitive information or cause a ...
CVE-2019-16969
PUBLISHED: 2019-10-21
In FusionPBX up to 4.5.7, the file app\fifo_list\fifo_interactive.php uses an unsanitized "c" variable coming from the URL, which is reflected in HTML, leading to XSS.