23andMe Files Bankruptcy, Consider Deleting Data; FOSS Needs Protection from AI Crawlers

The posts from the CA AG and the EEF include the steps to delete your 23andMe data. You also have an option to download your data if you wish. Make sure you review your settings for retaining your DNA sample (as in, destroy it), and your permissions for your genetic data to be used for research by third parties. Deleting your data also deletes your 23andMe account. If you decide to leave your data at 23andMe, keep an eye out for updated privacy/data protections, which will likely be accepted by your continued use of the service/leaving your data there.

It is interesting to note the any customers of 23andMe who are based in the EU can exercise their Right to Erasure (better known as the right to be forgotten) under the EU General Data Protection Regulation (GDPR). Also, under GDPR, individuals' person data is not a company's "most valuable asset" but rather belongs to the individual in question and is their data that has been entrusted to the company.

This is not the first time personal data has become an asset in bankruptcy proceedings. Back in 2009, Verified Identity Pass, Inc., which operated 'Clear' then, sold all the registered traveler data it collected for its airport checkpoints as part of its bankruptcy. Only strong legal rights to delete the data will prevent such a sale in the future. It appears that 23andMe allows for data deletion. It will be interesting and likely entertaining to observe the outrage that will ensue in a couple of years as some data centers engaged in machine learning and AI will inevitably fold, and companies will realize that they may no longer have access to or be able to delete, their proprietary training data and models.

Incidents like this are why I really struggle and to be honest no longer teach people how to protect their privacy. In today's highly connected world, it's impossible. Anytime you touch anything that is 'smart' or 'connected', your actions and lives are being recorded. Have Siri disabled on your phone? Doesn't matter, everyone next to you has it enabled. Walk in a parking lot and just about every modern car is recording who walks by the car. Your data is actively being collected by every entity possible. Then that data is then either hacked or sold to other entities (in this case both with 23andMe). I now teach people how to protect their digital lives with the assumption that your data is already out there and there is nothing you can do to get it back. I focus on behaviors like securing and monitoring all your financial accounts, credit freezes and IP Tax Pins with the IRS. It is the reality of the world we now live in.

Just remember, data is the new gold, and it will continue to be monetized even in bankruptcy. Laws aside, take charge of your information and request that it be removed from company systems.

Years ago my daughter gave my wife and me gifts of 23andMe testing, probably because during her teenage years I accused her of not being genetically related to me at all; After the results came in, I went through the deletion process. It wasn't trivial to do but not that hard, worth doing.

What could possibly go wrong? While 23andMe has been unable to find a legitimate and sustainable business model around this data, one expects that there will be multiple "data brokers" bidding for this data. When sharing your PII, consider the long term viability of the enterprise to which you are surrendering it. I tend to agree with my colleagues that, in the light of all the unregulated, not to say unscrupulous, data brokers, privacy is dead. However, in order to resist fraudulent use of our PII, I continue to urge everyone to lock access to their information on the three major credit bureaus and monitor all activity to their accounts on a timely, perhaps daily or even real time, basis. Prefer to pay online using proxies, e.g. PayPal, Apple Pay, Google Pay. Prefer financial institutions that confirm all transactions and changes out of band. (We really need a regulation that requires the credit bureaus to notify us whenever our information is accessed or sold in bulk.)

This is reminiscent of the impact search engine crawlers had on the web 25+ years ago, which resulted in our current mitigations. All crawlers, to include the "smart" AI ones, need to honor traditional restrictions, such as robots.txt, user agent, etc. Considering that after GNOME implemented Anubis only 3% of traffic was able to access the site, this shows the volume of automated traffic sites have to contend with, which is doubly annoying as open-source projects often rely on a provider that has limits on bandwidth or other resources for their server. Keep an eye on the ai.robots.txt project which has premade robots.txt files which implement the Robots Exclusion Protocol as well as .htaccess files which return error pages when detecting AI crawler requests.

The CAN-SPAM Act was landmark legislation addressing a vaguely similar threat 20+ years ago. Perhaps it's time we require web crawlers to obey robots.txt. Tell your representatives to support the CAN-BOTS Act! (I asked an LLM for a more creative name, and it completely let me down.)

Flow-down of security requirements is important, and properly representing the state of requirements passed down to you even more so. Better to have an audit finding and CAP (POA&M) than be cited for violating the False Claims act of 1863. If you're unsure, hire a third party to audit your security against the relevant standards; remember this engagement is working for you and is to get you where you need to be, and far less painful than an external audit. If you're working as a DOD contractor, brush up on CMMC 2.0 requirements, as these are real and have teeth.

With more and more companies outsourcing to third parties, the area of managing cybersecurity risk in the supply is becoming increasingly more and more challenging. All the questionnaires in the world won't prove what a supplier answers. The old adage of "Trust but verify" rings true, and companies need to look at ways to independently verify vendors' cybersecurity postures such as right to audits, independent audits, or appropriate certification schemes.

Having difficulty implementing cybersecurity contractual requirements is one thing, intentionally fudging cybersecurity self-assessment scores is another. Pretty easy case to argue they didn't exhibit a 'standard duty of care' in protecting customer information.

One of the things that came out in the investigation is that while MFA had been implemented, it had not been implemented completely, leaving entry points which were compromised. That means don't omit any users from MFA requirements, doubly so the admin user who has to authenticate N times a day and says MFA is inconvenient, as well as only implementing MFA on some entry points.

Seems like a relatively small amount to pay for an incident that caused so much harm... but then they did work with the relevant authorities. So let that be a lesson, don't walk, but rather run to inform authorities and you may, just may get a discount on your poor cyber hygiene implementation.

I cannot think of any other crime in which there has been so little sympathy for the victims. None of your constituents is likely to side with you if you fall victim to a crime in which the threat was obvious, the risk great, and the mitigation efficient. Think strong authentication and "zero trust." What's not to like?

The good news is Sungrow, SMA, and Growatt all acknowledged and fixed their issues, and they didn't require any action by consumers. Businesses need to consider these as another ICS with the corresponding controls, and all of us need to make sure that we're changing default passwords, our inverters are configured to update regularly, and they are on isolated networks. Many SOHO guest networks force device isolation, which would make an easy-button option for your Inverter, spa, and other IOT devices which don't need to communicate with any other devices on that network.

Just for context, in most Solar installations an 'inverter' is far more than just a device that just converts DC to AC. In many Solar installations, the inverter is the brains of the installation, connecting panels, batteries, backup generator, grid, etc. Think of it as an intelligent switching station that determines what power goes where, and in what format. It also monitors all systems to ensure the health of the installation, can do emergency switch-down when needed. The gotcha is due to the complexity of these systems, the inverters are often connected and continuously monitor. Even off-grid installations in rural areas will often have their solar installation connected to the internet (using Starlink or Cellular Internet connection) making them vulnerable.

Function aside, it's another ICS device accessible from the Internet and the same cyber security guidance applies. These sorts of gaps in basic secure by design will continue until Cyber Informed Engineering (CIE) takes hold at manufacturing companies. Till then, OT environments will continue to be targets for exploitation.

Some of the reports indicate the entry point is a login node which was unpatched, and running an old version of Oracle Fusion Middleware, which would be out of character for Oracle. That server is now offline. Regardless of their acknowledging the breach, you can verify that you're implementing MFA, reviewing access controls, monitoring for inappropriate access, as well as resetting any credentials you're uncertain about. This is also a story to bring to the table when discussing updates to SSO or ERP systems, which are typically slow or hands-off when it comes to updates.

While we are still no wiser (at time of writing) as to whether this breach is real or not, Oracle's communication around this issue has been very poor and leaves their customers in a very awkward position. I regularly say "You won't be judged for being a victim of a breach, but you will be judged based on how you respond to it."

Well now, isn't this a bit of a sticky wicket for Oracle. Denied the breach, yet some customers confirm. What's even more concerning is that the purported vulnerability is in, ready for it, Oracle Access Manager. If true, Oracle couldn't be bothered to patch its own product. While this gets sorted out, do the responsible thing, and rotate your credentials.

Hardly seems likely that there is so much smoke and no fire. Oracle would not be the first victim to refuse to believe that it had happened to them.

CVE-2025-2825, unauthorized access, CVSS score 9.8, is fixed in CrushFTP 10.8.4+ and 11.3.1+. Note you need a CrushFTP 11 license to update version 10 or earlier. If you have automatic updates enabled, you need to double check they worked and didn't leave behind a .jar_tmp which needs to be renamed .jar - note you only have to fix that one last time, it's been fixed to prevent recurrence once you're on current versions. Beyond updating, implement the DMZ feature of CrushFTP.

CrushFTP had issues assigning a CVE to the vulnerability. At this point, the CVE assigned by Vulncheck can be used for this issue, but there were some disputes with CrushFTP around issuing the CVE number. Too bad you never know until it is too late if your vendors have reasonable vulnerability management processes. The somewhat flawed automatic update doesn't make life better for administrators dealing with this issue.

After all these decades file transfer remains risky. We have seen a handful of tools prove to be vulnerable. Consider alternatives to FTP tools for sensitive data. Consider that your tool itself may be vulnerable.