Johnson Controls Discloses Breach Costs in SEC Filing; CISA Orders Ivanti VPN Disconnects; FBI Director Testifies on Chinese Threat to Critical Infrastructure

To give you an idea of why cybersecurity is often NOT the top priority of the CEO or Board of Directors: In their SEC filing, Johnson Controls notes they are carrying $96M of cost for dealing with asbestos usage/exposure lawsuits and are carrying $328M of liabilities for self-insuring “… liabilities for its workers' compensation, product, general and auto liabilities.” That $27M cost for this incident (after insurance payout) looks a good deal smaller in perspective. But, a relatively small investment in security operations would have likely avoided the full expense of this incident. If Johnson had avoided this incident, it’s reported profit for the quarter would have been 7% higher, not a bad return.

The attack in September by the Dark Angels gang claimed to have stolen 27Tb of data and sought a $51 million ransom, which is still more than the $27 million cost so far. Note that the cost includes lost or deferred revenue and business disruption, as well as costs which are expected to be covered by insurance. Make sure that if you're in a position to report the cost, you've got coverage for not only the cyber and IT activities but also the overall costs to the business.

While $27M seems like a big number, when put in the context of annual revenue of $26.6B, it isn’t. Additionally, the company carried cybersecurity insurance and given the cybercriminals demand of $51M for the decryption key, unlikely that they paid the extortion. Finally, with the SEC’s new cybersecurity reporting requirements, it is doubtful that they will change the reporting of the event to that of a material cybersecurity incident.

Any organization using Ivanti devices should see this as a strong suggestion to follow CISA's advise. In particular, note the section on how to assure the device is "safe" before reconnecting it. Take good notes. This will likely not be the last time to do this for your Ivanti VPN.

This seems VERY BAD. For context, it's very rare for CISA to issue such a short notice order, and it's also rare to see a factory reset directive. Ivanti admins take notice!

Clearly CISA & DHS's risk tolerance for the vulnerability has been exhausted. Emergency Directive 24-01 from CISA is consistent with Ivanti's recommendation: disconnect by 11:59PM Feb 2nd, export the configuration, factory reset, rebuild the device and upgrade to one of the supported/updated versions, import the configuration, revoke and reset any certificates, passwords and keys, then meet report by Feb 5th. There is one more step, due March 1st - assume any domain accounts associated with the affected products are compromised, necessitating resetting the passwords twice, revoke Kerberos tickets and tokens for cloud accounts on hybrid deployments as well as disabling/rejoining devices cloud joined devices to revoke those tokens. This is a good time to look at all your Ivanti installations and make sure you're not only on current supported versions but also what replacement would look like in case management's faith in Ivanti is a bit rattled.

At this point, how bad of a doom loop/doom spiral will this be for Ivanti? If I were a customer after this many issues on my primary security appliance, I would strongly consider an alternative technology. In today's remote worker/hybrid office environments, there are starting to be a lot of options. But this will not be a quick change for many massive companies (we are talking over 20,000 people). Expect this to be a fire drill for a long time.

A proactive measure by CISA given the urgency of the threat. Further, the steps to reconnect seem reasonable and straightforward. All-in-all, excellent updated guidance by CISA.

For many of us, raising the bar via basic cyber hygiene (patching, MFA, monitoring, secure configurations, lifecycle management) is a huge first step in thwarting attackers. Then partnering with your local security organizations/ISAC for focus on specific threats.

It is troubling that critical infrastructure has become a ‘soft target’ for nation states. More emphasis needs to be placed on securing critical infrastructure from cyber-attack.

These kind of security research tweets need to include more data and focus more on usefulness than click count. As far as I can tell there are somewhere around 220,000 active installations of Jenkins. If within a week, 80% of them have been patched that seems to be faster than Microsoft Exchange and other software critical vulnerability patch rates! Obviously, faster patching is better and patching will be a reality forever but real world business demands will always mean a week after patch release 10-20% will not have patched on premise software.

The number of CI/CD systems exposed to the internet is way too high. Considering what this system does, I’m surprised that self-hosted Jenkins versions would be publicly available. I understand that there are several public-facing CI/CD systems, but those were designed with internet-facing services from the start. Let’s say that Jenkins was not architected with this in mind. Why not just place your Active Directory domain controllers publicly facing as well?

As we’re a week into the vulnerability, having 45,000 servers unpatched is troubling. That said, we don’t know that affected organizations haven’t implemented the recommend mitigations – disabling the command line interface, changing key configuration settings – until the patch can be installed. If they’ve done neither, they fail the standard duty of care test.

This is just a count of public facing servers. Internal or external, make sure that you have your server patched. Keep in mind that CVE-2024-23897, the command-line interface flaw, can be used to expose SSH keys, binary secrets, credentials, source code and build artifacts. Even if you've mitigated, rather than patched, are you ready to explain why your server still showed up in a report of vulnerable servers?

Ivanti has had a rough start to 2024, we're now at four CVEs. CVE-2023-46805, authentication bypass, CVSS score 8.2, CVE-2024-21887, command injection, CVSS score 9.1, CVE-2024-21888, privilege escalation, CVSS score 8.8 and CVE-2024-21893, SAML server-side request forgery, CVSS score 8.2. Ivanti claims to have released an update on February 1st which addresses all known vulnerabilities. Read the Ivanti guidance carefully to determine if the fix is for your products. Note that they are recommending a factory reset before applying the update to prevent a threat actor from upgrading their persistence.

It appears that Juniper, err, Ivanti SSL VPNs have become a prime target for the attackers. These are installed in major organizations, and the flaws here are very bad. Please take a look at the next article for just how bad.

Threat actors are targeting EOL SOHO devices with critical vulnerabilities to construct their botnets. Odds are these devices "just work" and their owners aren't considering lifecycle or vulnerabilities as they just work. Fortunately, the FBI got permission to mitigate the infection as well as prevent recurrence. If you have SOHO routers in your environment over three years old, you should take a close look at their support lifecycle, and plan to replace them before that timeline runs out. Make sure they don't get put in storage where they can be deployed later. If asked, you may want to let them know that counting on the FBI to cleanup malware on your EOL router is not a viable plan.

How do we collectively manage devices that are no longer being updated by the vendor but can pose a threat to organizations? Is the organization that continues to use these end-of-life products responsible should they be used in a cyber-attack? Management of unsupported hardware and software is a critical security control, after all.

If some agency or organization urging for more security would fix the problem, the problem would have been solved over 20 years ago. Unless consumers will stop buying insecurity devices, they will continue to be offered for sale.

CISA “urging” and “asking” is just more noise. It is long past time for the US Government to be saying “we will only buy, and we will only allow connections from home users who buy, products that do NOT contain this short list of critical flaws.” Simple success example from the past: Back in the early 2000s, the US government required that all software using encryption, including browsers, could only be used in government if it had been validated against FIPS 140 requirements. Radical improvements in crypto quality followed.

Sadly we know from long bitter experience that "urging" manufacturers to make their products secure by default has no real impact. The US should look to the European Union which this week introduced the EU's first cybersecurity certification scheme to force manufacturers to make their products meet certain levels of security. Manufacturers who want to sell their ICT products within the EU will have to ensure their products comply with this certification scheme. More details of this scheme are on the ENISA (European Agency for Cybersecurity) website https://www.enisa.europa.eu/news/an-eu-prime-eu-adopts-first-cybersecurity-certification-scheme and press coverage at https://www.infosecurity-magazine.com/news/eu-cybersecurity-certification/ and https://www.euractiv.com/section/cybersecurity/news/eu-adopts-first-cybersecurity-scheme-to-certify-ict-products/. In addition, the United Kingdom's "Product Security and Telecommunications Infrastructure Act 2022" will come into force on the 29th of April of this year which mandates manufacturers of consumer IT products meet security requirements outlined in the Act https://www.gov.uk/government/publications/the-uk-product-security-and-telecommunications-infrastructure-product-security-regime.

Often these are built for price versus security. CISA is calling for automatic updates as a de facto standard as well as defaults being secure, along with strong wording regarding changing those settings, such as not enabling WAN based management. Also, CISA is calling for increased transparency on bugs and fixes to customers. Personally, I would also like to see Iifecycle/support information on the packaging of SOHO routers.

CISA can offer any advice that it wants. I also believe that SOHO routers and the SOHO devices that the ISPs provide should be architected with security in mind. But no ISP will overpay for these devices, and many consumers will not as well. Unless there is a regulation that forces this, only security-minded consumers will even consider this.

Access tokens, like passwords, need to be carefully handled. In this case the token provided 'unrestricted' and 'unmonitored' access to Mercedes' internal GitHub repo. While you may have different levels of access to your services and repositories, none should be unmonitored. Also, an "Internal" resource, with corresponding sensitive information, in this case everything from API keys and database connection strings to blueprints and source code, which is Internet Accessible, should have both device and user level access controls. Make sure you're aware of where your sensitive information, to include IP, is stored and how access is controlled. Then verify it's as expected.

GitHub offers a tool to scan repositories for secrets that could be leaked. Unfortunately, the company didn’t avail themselves of this valuable tool. Now Mercedes must deal with possible legal violations (privacy laws) and reputational damage.