@ryanstayloradobe https://www.jamf.com/jamf-nation/discussions/23236/jamf-pro-hotfix-release-coming-soon#responseChild140617

@donmontalvo is correct.

Yep, the issue is "We need to apply a patch because the vendor says to" doesn't fly at Change Advisory Board (CAB) meetings. YMMV

At the company I provide ITO services for, the Change Advisory Board (CAB) is filled with people that have the technical skills/knowledge to ask the question: what does the update fix? If we do not answer these questions to their satisfaction, then the Change is denied. Forcing us to go back to Jamf with the questions that they "should" have provided upfront.

From our TAM...

... we will not be releasing any additional information until we have given customers time to upgrade to this release.

Looks like everyone is towing the company line. No responsible disclosure, no CVE, no severity rating.

This is about trust. Either you trust Jamf or you don't.

If you change control group prevents the change then it's their issue. I am sure that Jamf did what they thought was best in a bad situation.

Us pressuring Jamf for more info is just wrong and I am betting even dangerous.

C

In case anyone has any feedback on how communication without putting customers at risk, perhaps you might want to upvote or share ideas here: https://www.jamf.com/jamf-nation/feature-requests/5842/better-discloure-of-hotfixes-concerning-security-vulnerabilities

Going to strongly disagree with that. Information could be released (CVSS score, zero-day? general info) without providing info that may compromise JSSes. What MANY of us are trying to say is, Jamf merely saying "hey, here's an important hotfix update" is NOT ENOUGH INFO for us to move forward.

I totally understand why they won't publicly release the info, but they need to do more to meet us halfway.

I have to chime in here with +1 for notifications. We have change management as well, not to mention that we are currently in a company-wide change freeze. I need to know at least something about the nature of what we're dealing with if I'm going to a) sell management on an exception, or b) put my @55 on the line by breaking the freeze. I get the need for secrecy, but OTOH we're paying customers, presumably responsible, and deserve to be informed about what it is we may or may not be installing in our environments.

@gachowski wrote:

This is about trust. Either you trust Jamf or you don't.

Not sure I'd ever agree with that. :)

Trust is for neighbors and lawnmowers.

NDA is for risk management.

There's more to this than just security.

There's also the "Scream Test" avoidance factor. ;)

Thanks for the heads-up. It would be useful to provide additional information like

• what is the risk


• are there ways to mitigate until the update can be installed

I appreciate having received an email with the announcement. But seeing URLs like "http://mkto-p0016.com/xyz" when doing a mouse-over on the links in the email does not increase the confidence in that email. Who is mkto-p0016.com? Why is it only http?

I feel there is room for improvement.

@mschroder mkto-p0016.com belongs to https://www.marketo.com/

@rderewianko I thought so, but is that a reason to consider a http URL to that site sufficiently trustworthy to click on it to get an important security update?

Disclosures aside if a vendor releases a security patch that is not a scheduled release due to a vulnerability they are fixing, you should still be able to accomplish that in your Orgs. We have change management in place but if you've been in IT for more than a few years odds are you have had to do emergency patching in the past. Your process should allow for emergency patching.

If your process really halts you due to lack of disclosure I think you should maybe re-evaluate your process. We were able to get it tested in our test environments. Run our validation tests. Collect data and test some more, and then ship to production with in maybe half a day today.

While I am not excusing the lack of communication and disclosure I do understand that an unscheduled hotfix to patch a vulnerability is enough reason for me to run the patch through my environments, validate it is good, nothing else breaks and ship it to production. I honestly think if you have to go through a review board for change management you may want to re-evaluate your process, or streamline it where things don't take months or longer to deploy.

Given the fact a disclosure was not communicated clearly before or during the hotfix leads me to believe disclosure will happen later on after customers have had a chance to patch their environments. This was probably due to jamf wanting to mitigate people using the exploit. Leaving it unpatched because of unclear communication is not very responsible in my personal opinion. Whether you agree with this approach of disclosure or lack there of is a separate subject in my opinion over say ensuring the security of your Org. While I also want to hold every vendor to properly QA their products so new bugs aren't introduced in a patch/upgrade I also think your Org should do their own due diligence of testing.

I would like to see more disclosure on this and I would be okay with a security to security conversation where jamf can just disclose the issue to one of my security engineers and let my security handle it from there. However, I do think if you can't make a change, especially a change due to a patch for security you may want to re-evaluate the process you are currently stuck in.

Is it a big enough issue that I STILL haven't been notified by Jamf directly about this hotfix?

That doesn't inspire "trust" in Jamf.

Putting aside personal preference and opinion, the simple fact is CAB exists to protect companies from disruption and subsequent financial loss from unnecessary changes. I'm very happy for folks who aren't burdened with this inconvenient reality. Really. I wish the rest of us had it that way. :)

With that said, I agree with those who are simply asking for enough details to push the hot-fix through the CAB process. We're not looking for in depth details that would enable bad hombres. We're looking for the base level information necessary to warrant applying any hot-fix. Of course NDA applies in these scenarios.

What we are trying to avoid is another "You guys really need to upgrade" advice from Jamf, and subsequent long threads about how the update/upgrade blew up in their faces (yes, even though carefully tested; you simply can't cover every possible scenario in a lab). You know, companies don't want to be a "Scream Test" for a product.

As long time customers, many have Encompass, we look forward to the point where Jamf matures/grows to the point where it can better accommodate the needs of stricter environments.

For the record, Jamf is the best product available for managing large numbers of Macs. It is manageable, sustainable, and fully supported.

the simple fact is CAB exists to protect companies from disruption and subsequent financial loss from unnecessary changes

If you don't patch security holes though, you are setting yourself up for disruption and possible financial loss. I totally get the whole do your own due diligence to mitigate risks and protect stake holders and I support that. I just think if it takes you a month to patch something that is too big of a risk to take is all.

At the very least you should still send this to your change board with the information that this is for a major security patch. If they decide not to move you at least did your job and communicated the risk. While jamf did not come out and quantify the risk the fact that it was an unscheduled release to fix a security hole means it is significant in my personal opinion.

@tlarkin wrote:

it is significant in my personal opinion.

You just validated the reason CAB exists. :)

I have to agree with @tlarkin on this one. Any good CAB will have a process for this type of thing. Generally speaking, I need to request a change over 2 weeks beforehand, but we also have an emergency procedure for just this type of release; an unplanned vendor supplied security release.

This is highly irregular for Jamf. I would recommend that if you haven't already patched your systems, you do so soon. If your CAB is blocking you, make sure you put forth the effort to get things patched so that when the vulnerability details are released and it's as bad as I think it is, you can hopefully amend your processes to be able to address this scenario.

I think there are two (or more?) scenarios...

1. You are at a company that doesn't have strict CAB processes (meaning exceptions are given).


2. You are at a company that has stricter CAB process, where even emergency changes require vetting/rating, where there is a minimum info baseline for vetting. (*)

(*)"Apply this fix, because we say so." <-- For #2 this will get you laughed out of CAB, and you may be assigned an action item to get the necessary info. While this thread shines a light on that, the real communication is happening offline, directly with the vendor, and may involve an NDA.

CAB covers any change, not just hot-fixes. Any notion that folks in scenario #2 can "just change the process" to get a vague hot-fix applied may be a bit of woolly thinking.

@donmontalvo "minimum baseline for vetting" could be that "vendor advised this security update is needed, it's sever enough that they have mentioned on their public forum that thy will only disclose why once a large perecentage of folks have applied the patch" (with a link to Jen's posts here).

To add to the above, the hotfix will also be vetted by being installed in test.. before applying to prod. So you have the vendor strongly advising you to apply the hotfix & you've tested on your inf before rasing the request.

If this doesn't work.. wait it out. Hope this is not something that puts your orgs at massive risk & is exploited, honestly. And if/when jamf does advise, don't moan.. just apply the hotfix & go via your processes.

@bentoms wrote:

@donmontalvo "minimum baseline for vetting" could be that "vendor advised this security update is needed, it's sever enough that they have mentioned on their public forum that thy will only disclose why once a large perecentage of folks have applied the patch" (with a link to Jen's posts here).

For those in scenario #2, that would fall under "getting laughed out of CAB".

As mentioned, you're just going to get kicked back for more info, which Jamf needs to provide.

If this doesn't work.. wait it out.

That's a good way to get fired, and possible become unemployable. ;)

Hope this is not something that puts your orgs at massive risk & is exploited, honestly.

Yep, that's kind of why this thread exists, the missing context is putting customers in scenario #2 at unnecessarily higher risk than is acceptable.

And if/when jamf does advise, don't moan.. just apply the hotfix & go via your processes.

When Jamf advises, the CAB will have the missing context needed for approval.

Then, hopefully next time a better process will be in place to accommodate customers in scenario #2.

@donmontalvo I'vet been on a many CAB's, & have been in this situation with vendors before.

I've yet been "laughed out of CAB" for doing my job by installing a patch, on vendors advisement due to a vulnerability that is not at the time of CAB disclosed.

And, historically, it's been the right thing to do the apply the patch.

Yesterday I patched all of our MSP customers JSS's, no issues seen. Went well & as smooth as testing in our various test environments went.

I totally understand Jamf not wanting to release too much information on this to mitigate risk, however I think people here and CABs would be satisfied with the same level of disclosure as Apple with this sort of thing. It doesn't have to specific, just enough for an org to mitigate the risk with other controls whilst going through a testing, CAB and patching process.

i.e Risk: Possibility of remote root access to the JSS
Response: Lockdown all remote access to the JSS with Firewall/s whilst testing is being carried out to validate patch.

This is not the case though. We don't know if it is a client or server vulnerability or how severe.

This is still vague yet gives you enough to go on, even if it didn't have the CVE ref.

@bentoms I'm very happy that your CAB process experience has been so smooth. Really. I truly am. :)

@PatrickD posted:

This is exactly the type of context we are looking for. When Apple releases security updates, CAB uses this type of info to vet/rate. Kudos for posting the example.

Jamf are probably discussing it internally now, and I'm confident their process will be more accommodating in the future.

Study material for Jamf...

Apple Security Updates
Microsoft Security Bulletins
Adobe | Security Bulletins and Advisories
Mozilla Foundation Security Advisories
Google Chrome | Security Fixes and Rewards
Oracle | Critical Patch Updates, Security Alerts and Third Party Bulletin
Citrix | Support Knowledge Center
McAfee | Product Security Bulletins
Symantec | Security Updates

@PatrickD & @donmontalvo I wonder if this conversation is conflating things.

I really hope that, folks are doing the update & are able to put it through their CAB. But that the discussions are more in regards to better process next time.

Jamf definitely needs a better process.