Fluent Bit Puts Cloud at Risk; SEC Breach Reporting Update; Unpatchable D-Link Flaws Exploited

Ask any cloud service providers in use if they use Fluent Bit and are they on the latest version and if they can assure you that use of an older version did not lead to compromise.

If you're using Fluent Bit, make sure you've updated to 3.0.4. The harder question will be asking your cloud providers if they are and which version is in place. If you're referencing a provided SBOM, make sure that it is both current and that you're checking the Vulnerability-Exploitability eXchange (VEX) data for applicability of vulnerabilities.

This goes back to things like SBOM and Cloud Providers. If your cloud provider is using this and patches it, you will never technically know about it unless you have these libraries exposed to you. Then again, how do you know they fully patched it?

There is no patch for these vulnerabilities. Yet another reminder to track the "End of Life" of devices. Some recent approaches to "device safety" labeling to consider adding an expiration date to indicate how long a particular device will be supported. Most consumers will likely be surprised how short this time is, and maybe some expired devices are still rotting on store shelves waiting to be sold to unsuspecting consumers.

At the user level, the solution to this problem is simply to replace the device. The improvement in performance and function will more than likely cover the cost of the upgrade; risk reduction will come as lagniappe. At the community level, many, not to say most, of these devices will never be replaced and may be co-opted into bot-nets. We should consider legislation that would allow ISPs to coerce their customers to upgrade.

A lot of attention has been paid to flaws in Adobe's PDF products like Acrobat. However, Foxit's solutions had very similar flaws, and they are exploited just like the bigger competitor's flaws.

Foxit positions themselves as more affordable drop-in replacement for Acrobat. This attack relies on social engineering, prompting the user to enable/allow behavior which may seem innocuous, but in totality allows for the malware to be installed and executed. The root cause is in how Foxit is designed rather than a coding error. Even so, educating users on how to handle the unexpected prompts for privilege or command execution, similar to your existing social engineering preventative training, are your current best mitigations.

The 2024 Verizon Data Breach Investigations Report highlighted that over two-thirds of breaches analyzed included a non-malicious human element. This vulnerability does just that: it takes advantage of human nature to routinely accept the default option for pop-up windows. Take a moment to think before clicking.

In my experience, community water systems are often small, running on systems which are enough to get the job done, and don't have the resources for in-depth security assessments. While the 1433 section only applies to systems with over 3300 users, it's still a good idea to have your arms around where your risks are and what you can do to keep from being a victim. Regardless of size, leverage the Water ISAC resources below. Membership is based on customer base, starting at $105/year, and even has a 60-day trial so you can see if it is a fit. Given that critical infrastructure like this is a constant target, opting out or ignoring your security posture really isn't an option.

The alert highlights two things that make it difficult for communities to comply: 1) lack of technical skills to conduct the cyber portion of the RRA; and 2) resources to implement the findings from the cybersecurity assessment. Both are solvable but require funds at the federal level and likely technical support at the state or local level.

While many of these systems use the some of the same software and share any vulnerability, unlike the power grid, one cannot be used as an attack vector against others. While any compromise will be serious, consequences will remain local.

Of note here is that MediSecure's contract with Australia's health network was awarded to another provider last May, and the transition completed in November. It appears customer data was still available in their systems. The call to action is to review how your data is protected when services are transitioned to a new provider, what is their disposition process, to include any third party services they leverage. All that should be in writing and validated on a regular basis.

This one is a good reminder to have information removal/deletion/transfer clauses in all subcontractor/service provider contacts so that sensitive information is not stored at losing incumbent vendors any longer than necessary to support full turnover to new service providers.

Although specifics on the attack are not available, it does reinforce the need for regular risk reviews of third-party vendors. Often there is reliance on a vendorÕs cybersecurity process and that must be taken into consideration as part of your information security program. Use this attack as an opportunity to revisit and update your third-party risk management program.

As a ham radio operator (K3TN) this one hit home! The ARRL hasn't put out much information, but many systems remain unavailable a full week after the incident. This will be a good case study for the IT and IT security problems small/medium-sized non-profit organizations face with small IT staffs. Pressures to meet demands for new services often consume staff and budget that are needed to assure reliability and security (today's buzzword is 'resiliency') of existing crown jewel services. Another common problem: CEOs and Boards need to have it driven home that security through obscurity ('Who would attack us??') doesn't exist on the internet any more than it exists in Tornado Alley.

ARRL is saying they don't believe the member database is affected. And while the information is public, much is available from the FCC, that database represents an authoritative connection of that information to the member. If you're an ARRL member, be on the watch for phishing emails leveraging your information.

The ARRL is the communication system of last resort in the event of a "Black Sky" event and may be required to coordinate a cold start of the grid. However, it is highly resilient, and this application is not a single point of failure.

This is an interesting observation. If you own a site, you control the lifecycle and have the say on what is left vs archived/deleted. The question is what is the obligation to sites referencing that content? How far should sites go to maintain continuity/pointers to the most current versions? This is something you should discuss and document at your shop. Having a consistent approach which is written down is more important than the decision you make. Give consideration to publishing that on your site.

Do we need to archive the internet? If so, who is doing it, and how is that being funded? For those that have never investigated this, there are groups out there backing up and archiving pages on the internet and large data sources and some of them have funding, but many don't. Is it digital decay or totally lost knowledge pools? I would argue that this type of Internet historian, librarian, archivist, or even archeologist may be a job title over our lifetime. Probably dedicated to preserving pages although that webpage that was created using GeoCities with the big warning sign may be the target. Or maybe it is.