Who Will Notify Change Healthcare Victims?; Fix Ivanti EPM Again; OpenSSF Threat Intel Sharing

Because what is really important after a breach is to find a way to abscond your responsibility to customers. If you lost the data, you need to notify. The entity suffering the breach should also have the best information identifying what data was exactly lost.

On the face of it, the 100+ medical associations have the relationship with the affected individuals, not the out-sourced billing provider. That said, Change Healthcare should make those medical associations whole for all costs associated with this security incident. That includes the costs associated with victim notification and any credit monitoring services offered.

In our interconnected world, this question is likely to arise again and again. We must await more experience to arrive at a general rule. That said, Change Healthcare continues to have other priorities for the moment. One hopes that this question does not distract them.

Yes, this is a different flaw than the one disclosed and exploited last week. I am afraid these devices will need a flamethrower patch to properly secure them at least until July.

At this point, Ivanti has released a hotfix for 2022SU5 which replaces four DLLs. You need to unblock the installed DLLs, back them up, replace them with the new ones, then reboot your server. Alternately you can close the EPM console and run IISRESET if you can't reboot. Either step is critical to ensuring the new DLLs are loaded.

Expect vendors to pick up the pace in announcing PQE protocols in their tool suites. This follows announcements by both Signal and Apple earlier this year. Organizations should still determine the level of protection their data requires before implementing, as older equipment may not operate or have limited functionality with the increased key size.

Zoom is adding Kyber 768 to their E2EE, where the encryption keys are only provided to participants, as is the case for standard E2EE, claiming their servers don't have these keys and therefore content is indecipherable. As with other PQC offerings, it's a good idea to test it out and keep an eye on it as it matures. Before you click, check the product and version support as well as limitations in their KB article "Using end-to-end encryption (E2EE) in Zoom meetings (https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0065408)

Good move. While holding a meeting, one should not have to worry about whether the content of the meeting might still be sensitive when quantum cryptanalysis becomes efficient.

Searching shodan.io for rockwell, siemens, schneider, etc. yields many thousands of operational technology (OT) devices. Connectivity options for OT should be, in order: none/true air gap, data diode, MFA-protected VPN/private network. Sadly, the people who really need to hear this almost certainly don't read NewsBites.

This is practical advice and should be a part of your cybersecurity program. DonÕt give the adversary more attack surface than necessary to manage business operations. While you're at it, take the opportunity to ensure that any vendor supplied default passwords have been changed.

It's not safe out there; make sure the only devices youÕre exposing directly to the Internet are those that are designed for it. Even so, you want to isolate your IOT/OT devices to restrict unwelcome advances, or leverage of unmitigated weaknesses. Remember to review how devices and sensors deployed "in the field" are accessed and protected. Review protections based on older threat models which may no longer be accurate.

While Rockwell issued this advisory to and for its customers, it really applies to everyone. Not only do these devices increase the attack surface gratuitously but they are the components from which bot-nets are built. Take advantage of the guidance that Rockwell has developed for its customers.

This addresses CVE-2024-4985, authentication bypass vulnerability has a CVSS-B core of 10.0, and CWE-303 incorrect implementation of Authentication Algorithm which impacts all versions of GHES prior to 3.13.0. Even if you're not using SAML SSO, or SAML SSO without encrypted assertions today, you're going to update to the fixed version. Read the release notes, there are other improvements in 3.13 which also improve performance, logging and security such that you may want to target going all the way to that version.

Many organizations have moved to SSO for user convenience and likely also use it to access GitHub resources. They also have likely implemented the optional encrypted assertions feature to protect communications with the SAML server. As this vulnerability is rated a 10 on the CVSS severity score, prioritize patching in hours not days or weeks.

XSS flaws are often underestimated. I think this particular vulnerability is a great example of how bad a relatively "simple" XSS flaw can become. XSS exploitability if often limited by the imagination and creativity of the attacker. Defenders tend to underestimate both.

CVE-2024-4835, a 1-click XSS account takeover flaw, has a CVSS 3 score of 8.0. The prior GitLab account takeover flaw, CVE-2023-7028, is under active attack, so you really need to make sure you've applied updates to mitigate these flaws being taken advantage of.

As this is the second security incident CentroMed has experienced in past year, an independent review of their cybersecurity program is warranted. Better to get ahead of this before multiple lawsuits are filed.

This is their second incident in a year after falling victim to the Karakurt extortion group in June 2023. That incident impacted 350,000 individuals and claimed 42 GB of data, which wasn't leaked publicly. While security isn't perfect, none of us want to be in that "not again" conversation. Conduct a tabletop of how you would respond in a similar situation. Identify scenarios where improved cyber defenses could still fail and take steps to minimize that.

CVE-2020-17519, which allows for an unauthenticated user to read any file on the local JobManager file system through its REST interface, was identified as under attack by Palo Alto's Unit 42 back in November 2020 and January 2021. At this point hunt down your copies of Apache Flink, if any, and update them post-haste.

KEVs are urgent priority patches. The fix date that CISA dictates for Federal agencies should not be taken as license to delay.