[tejaswiy]

> Second, Smith blamed a scanning system used to spot this sort of oversight that did not identify the customer-dispute portal as vulnerable. Smith said forensic investigators are still looking into why the scanner failed.

Do these scanners ever work? Without naming names, the only reason we used this at a previous company was to kind of handwave around hey we have this tool doing regular security checks.

> The first excuse Smith gave was "human error." He says there was a particular (unnamed) individual who knew that the portal needed to be patched but failed to notify the appropriate IT team.

How is this one individual responsible for tracking all IT security vulnerabilities in all the technologies that equifax uses across its stack? How do they not have an admin team whose job it is to do these things?

[jeremyjh]

We do not know anything about the number of people who could have known about this issue and escalated it, but it does not surprise me at all that there is one primary person who is responsible for it. In fact, if there were not exactly one person who is responsible for the security of the application that would be a different sort of problem as diffuse responsibility can be neglected quite easily in large organizations. Still, at my own company - A LOT of people were focused on the timely remediation of this issue and there was no chance of it being left to one person, even for development environments of internal facing applications.

The scanners do work, we used them at my company and they found this specific vulnerability. It surprised some development teams because there are libraries that use struts without really advertising it, so even applications that don't "use struts" had a transitive dependency on it, it was running in their container and showed up on the lists that were circulating.

[athenot]

> Do these scanners ever work?

Yes they do. But you have to have a process to triage what the scanners produce, and have a team whose job it is to keep the ops/dev side accountable.

They are quite useful when scanning all the internal parts of a datacenter. There's a fair amount of nitpicking but it helps weed out the obvious (like installing some open source package which defaults to some bad cipher for SSL, or leaving internal links unencryped under pretext that it's "safe behind the firewall").

Often, though, the issues flagged by the scanner trigger deeper conversations about security. That's where the real value is, but that requires an organizational culture that actually cares about security. Instead, many companies just throw money at the problem of "security" and consider the scanner will fix all their issues with zero effort.

[wglb]

> Do these scanners ever work?

See https://www.tenable.com/blog/apache-struts-jakarta-remote-co...

Yes, they do. Detecting the flaw is not a problem, but often operationally patching can be a big deal.

[dba7dba]

This reminds of a fairly well known online/offline service company that does not patch their production Windows servers at all. Their mode of defense is firewall. Apparently they has some servers/apps breaking when Windows servers were patched, so they do not patch their servers at all.

[wglb]

From the Ninja Threat Model at https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...: The attacker is going to sit on the same network segment as the application. There’s no firewall or filters. There’s a special place in hell reserved for products that require firewalls or filtering to protect themselves against attack.

[caseymarquis]

I just ran into a company who has updates disabled on all Windows PCs, leaving them as the stock install. Their IT got defensive about it very quickly when I asked them to allow us to update the PC they were running our software on. They don't handle consumer data, but they have their own set of problems which could come from a data breach.

[skarap]

> the only reason we used this at a previous company was to kind of handwave around hey we have this tool doing regular security checks

That's the only reason for most of their clients. "We get periodic security scans from a respected vendor, yes sir!".

I can't rule out that the scanners might work, but if the vendor isn't naive, they'd be optimizing for their real target audience.

[nwatson]

Having personally seen the sausage factory on one of the "scanner" companies, I would be very careful and do due diligence on any such thing I contemplated buying.

Compliance & Security "in the enterprise" is a smoke-and-mirrors game full of weird terminology divorced from the nuts-and-bolts issues with people who don't know what they're selling engaging with people who don't know what to buy, playing the industry-form and trade-show and junket and relationship game (probably no different from the DB market, the network market, the ERP market).

The DKs that fail at technology and don't really know it move on to these segments of the security market, to everyone's detriment.

[mikekij]

Apparently the right user:security engineer ratio is 143,000,000:1. /s

[jstarfish]

> How is this one individual responsible for tracking all IT security vulnerabilities in all the technologies that equifax uses across its stack? How do they not have an admin team whose job it is to do these things?

They do have a vulnerability management team; the responsibility does not fall on one person.

For all we know this unnamed individual is just a low-level developer, analyst or pentester who had some knowledge of the exposure and failed to act.

[tehwebguy]

Maybe he was talking about himself?

[dboreham]

>Do these scanners ever work?

For this particular vulnerability? I doubt it. (Source: I worked on building such a scanner recently).

Let's begin with a vulnerability that is obviously detectable with an off-the-shelf scanner: "Buffer overrun in Linux CIFS Server". We can detect a host with this vulnerability by simply scanning the local subnet for live IP addresses then fingerprinting the host to determine it is Linux, checking if it responds on the SMB port and finally sending it a test exploit payload and see if it responds in the expected way (or crashes). This all takes a few ms.

But now consider what if the vulnerability is only exploitable by an authenticated session? Well we could have our scanner ask the operator for a set of credentials for each CIFS server it finds. But what if the vulnerability requires a mounted share? Well the scanner can ask the operator for the name of a share, or if it is lucky it could try to guess one. Perhaps we could be happy with the scanner identifying the version of Samba running on the server and concluding from patch history knowledge that it is vulnerable. But boxes get locally patched and often there isn't enough information in the externally visible version info to tell one way or the other.

Now think about trying to do this in the context of the vulnerability "If your application uses Struts and allows file upload then it might have this RCE vulnerability". We don't even know if we're using Struts in any of our applications. We may have hundreds of applications. Is it possible to tell from the outside that Struts is being used? (I'm not sure but probably not). You could note that the web server is Tomcat and therefore the application is written in Java and therefore it might use Struts. There will be hundreds if not thousands of potential CVEs to check for given only that information.

You don't know if a given web application even supports file upload. How to you tell? Look at pages for the string "Click to upload"?? (Yes I have seen this done).

Given that it is often a hard task for a human to figure out how to use one of these applications, and that they would need to possess all kinds of valid data to even get the application into the state where it permits file upload, I think you can see this is not going to be easy.

Add in the fact that each state change may take a sizable fraction of a second and there could be thousands of plausible vulnerabilities to check for. The driving of the application has to be done inside a headless browser process which will often sail off into space paying you no heed..

Even if the 10,000 monkeys happen to type Shakespeare, there will be a mass of false positive results in the report which a human has to trawl through.

And the scan will not complete in finite time.

Not so easy after all.

What is relatively easy is to have humans keep an eye on the applications for which they are responsible, reading the security mailing lists for the dependencies and taking appropriate action.