Hacker News Reader

Comment by scjody | Hacker News Reader

The product I work on is geared towards big corporate IT environments, and I can confirm that this sort of thing is not unusual at all.

A recent support ticket went along the lines of:

Customer: An audit discovered that JDK version X was installed as part of your software. It has a vulnerability and we demand a way to upgrade to JDK X+1 that has the fix.

Our support team: We're already aware of that and the latest point release of our software bundles JDK X+2, which fixes that vulnerability and 2 others. Please upgrade.

Customer: Our compliance team requires JDK X+1. Please provide a way to install this version.

We eventually solved the problem by having them upgrade to the latest major release of our software, which doesn't use Java at all, but it boggles my mind that they wanted a _less_ secure JDK.

View on HN

After years of being beaten by customers with stories like these, I learnt to treat InfoSec and Compliance teams as finite state machines, particularly at banks and other financial institutions. Learn not to question the sacred spreadsheet, or debate the merits of a request. It's pointless, and you keep rolling your eyes will only end up with you at the optometrist.

Instead, treat compliance like part of your API. Ensure your product delivers on the expected answer, while continuously improving the security of your products in the parts that are not directly visible.

However DO get in writing that the option was offered to them for possible future court battles so that the onus was on them for failed security damages.

Maybe JDK X+1 had gone through a deep and thorough review at some point that got it put on some "OK" list somewhere? And maybe X+2 was too new to have made it through that same deep and thorough review. It makes sense from an auditor's perspective, maybe X+2 has new bugs that X+1 didn't have. They want the good version, not the newest version.

Maybe. Doubtful in practice, though.

Actually it's super-realistic in practice, especially the JDK, given the short-short-long support duration cadence for JDK releases. e.g. I am totally uninterested in someone telling me I need to use JDK 12 rather than JDK 11: the former is already out of support and the latter will be supported until at least 2026.

They could be referring to the list of FIPS-validated crypto modules.

OP's story and the article's author are kind of missing the point. These are both simple stories of a vendor failing to meet a [presumably] written requirement: The customer, or regulator, required X, and vendor decided instead to provide Y, and then were dumbfounded when that was deemed unacceptable. OP's vendor went farther, offering Z instead, and the customer again reminded them that X was required. It doesn't really matter if there are better alternatives than X. Those alternatives are not part of the requirement.

Whether Y=X-1 or Z=X+1 is irrelevant. Customer requires X, you provide X or they'll find another software vendor.

I doubt they cared as much about security as ticking the compliance checklist.

That was the point of the comment.

True, but competent company management / security professional would see version x+2 and go ahead and tick the x+1 item off the list.

That’s not really the case. Version X+2 is not automatically better than Version X+1.

It may have fixed known vulnerabilities a,b, and c but introduced vulnerabilities d, e, f, and g. How would anyone know?

Correct! And for the auditor, version X+2 has not been evaluated and certified, so they cannot really "approve" it. When one realizes the auditors are simply doing their job, and the end goal is more or less the same, the going gets much smoother. :-)

This sort of "it's not been vetted and approved" business can get really silly though. Like one company I worked at a couple of decades ago that mandated Windows 95 for employees. IT staff would actually take new machines shipped with Windows 2000, wipe them, and install the corporate Win95 image.

A common mistake I've seen in the industry is to "look down" upon the IT staff, which makes it much difficult to get a meaningful conversation going.

Yes, wiping W2K and installing W95 is problematic and insecure, but I always believe in the power of a polite conversation and have had great success in persuading the powers-that-be to change their stance. :-)

Oh, but I was IT staff at the time. I wasn't in charge of desktop support, but I knew the guys. They didn't care for it either, it was policy from a high level in a company that, as a whole, did look down on IT. One of my coworkers actually went through the whole process of talking and negotiating to try to get a Win2K laptop instead of having W95 forced on it. No luck.

And, if anyone has been wondering, yes, there was hardware in the brand-new laptop that W95 didn't support. It "worked" with a generic fallback driver but lost some of the functionality that made the laptop worth buying.

This is something I would totally understand. Many software packages had compatibility issues when moving from 9x-based Windows to NT-based Windows (like expecting they could do things that NT didn't allow), so the last thing you want to some random person complain that their computer is broken. Everyone gets the same system, where the issues are at least semi-known.

Eh -- for some software packages, maybe. I probably trust that new versions of the JDK are generally better, and probably have fewer security issues, or at least fewer known security issues, but I definitely don't trust every new version of every software library or package. New security bugs are introduced all the time, and if a new version represents a major refactor or a change of maintainer, it also represents a major unknown.

This is true in general. But this also applies to the mandate to upgrade from X to X+1. For most (but not all) software it is fair to assume that a patch version does not represent a major refactor.

If something does go wrong, the people who approved x+2 will be the first ones handed pink slips and the bureaucrats will get a finger wagged at them. That's why it's better to comply and have it noted that x+2 was offered but ultimately poo-poo'd by management.

One of the big companies in corporate security compliance is literally called Checkmarx. They couldn't be any more honest about it.

https://www.checkmarx.com/

I feel kind of betrayed that this domain is not hosting a communist interest group.

Well how do you know that newest version is not having even worse security issues??

You argue that people should just install latest versions without thinking? This did not went well with SolarWinds case.

"but it boggles my mind that they wanted a _less_ secure JDK."

This should not be hard to understand at all.

A lot of things may have changed in those revs, beyond the 'extra patches - those affect systems. It's likely the software was not approved in the new operating environment.

You can just go ahead and use Java 11 on software designed for Java 8, there may be issues.

The 'patch' that go into one rev is what they want - not more.

Most individuals are not qualified to make versioning decisions.

The larger the company, the more at stake.

It's possible it was due to bureaucratic numbness, and the agent probably should have maybe 'checked harder' about the new versions, but wanting a specific version is reasonable depending on the circumstances.

Our Support Team: We will be happy to comply with your request once you sign this liability release form indicating that you want the less-secure X+1 update, and not the more secure X+2 update which we recommend.

Reply on news.ycombinator.com