4 ms·
> Large orgs should already have sufficient documentation as to which packages and versions are in use and what systems pulled them from their proxy repo. Key
by riskable 5y ago
> Large orgs should already have sufficient documentation as to which packages and versions are in use and what systems pulled them from their proxy repo.
Key word there: "should".
Let's say you have all your 50,000 applications well-documented. You think those docs are all going to be searchable in one place? That's an information disclosure vulnerability! No, all 50,000 applications documentation will be silo'd and only accessible to a select few people who work on them (you hope).
So now something like the log4j vulnerability crops up: You need to find out which systems are using log4j and what version. Best you can do is ask around... Demand that every application team cough up the details ASAP.
Now let's say you get data (emails) back suggesting that 5,000 applications are using log4j for certain, 1,000 may be using it (they're Java based apps), and you've confirmed that 14,000 most certainly are not using it. That leaves 30,000 applications where you have no idea if they're vulnerable.
You get data from the Artifactory ("proxy repo") team and they tell you, "we have 150,000 servers that have pulled down log4j (various versions)." Well, that's not particularly helpful so you get the raw data and try to correlate servers to applications only to find that's not helpful either: Because multiple "applications" could be using the same server and just because a log4j version was pulled doesn't mean it's actually being used by anything (in production).
After a few days of investigating the issue you find out that some thousands of applications actually are using log4j but it was included as part of a dependency. You tell them to update it.
Then you find out that 10,000 applications at present have no active development teams which explains why you got no response. Then there's an ungodly number of applications where no one has access to the source code anymore, 3rd party applications, etc.
So even if you have a central proxy repo and excellent documentation on all your stuff that doesn't mean it's going to be easy to hunt down and patch everything (that needs to be patched).
- giantg2 5y agoPretty sure the various organizations within the enterprise had an individual responsible for their domain. At worst, it's a bit bucket search within ones org/domain for the library. The testing is the more complicated part. It's not an easy situation either way, but the identification portion should be trivial.
- ygjb 5y agoDepends on how the organization grew, and if they have unified processes across department. AFAIK the IT security folks at a financial institution that I used to work at are living in hell at the moment. That organization grew internationally through acquisitions across more than 80 countries, and lacks unified structure across the entire organization due to legal and compliance constraints unique to each jurisdiction. A web development shop I provide security guidance to (owned by one my TTRPG buddies) had to do a couple of searches in github and update some hardware as patches became available. We made sure he was sorted out over a couple of drinks before we played board games. It varies.
- giantg2 5y agoThat does sound like a nightmare.
- greedo 5y agoSure. We have a codebase and app stack that has grown over 40 years. Responsible Parties have come and gone, sometimes handing off ownership responsibly, but often there wasn't enough time. So someone may be "responsible" for application X, but they haven't looked at the code in any detail. Or application X was installed by a vendor who provided documentation back in 2002 that is long gone. Nothing is trivial in large organizations.
- giantg2 5y agoI mean, we could say nothing is ever trivial, period.