Gartner Researchers: Organizations Need to Change Mindsets About Prevention and Recovery; Broken Undersea Cables Disrupt Internet Service in Africa

There are two points being made here. The first is that you need to train and plan for an incident. Develop plans based on tolerable impact which would allow responses to be prioritized. The second is that you need to look out for the well-being of your responders. Staff more than one shift, monitor for stress and mental state, make sure they acknowledge work they have done, even taking credit for small incidents to show they are making a difference.

Business continuity plans that are rehearsed and drilled have been identified as both essential and efficient for decades. They are the security measure of last resort; we invoke them when all else fails. The success of ransomware attacks demonstrates that many are not nearly as robust as they need to be. That said, prevention remains the most efficient part of one's strategy.

You can’t talk about prevent and recovery without also including detection. It’s akin to having fire detectors installed. You can never, completely prevent a fire, but you do want to be able to detect one and be able to reduce the harm from it. And yes, you should regularly test the recovery plan. That’s why organizations regularly have fire alarm drills.

The impacted cables are deep, about 1.86 miles, which rules out human activity (ship anchor, fishing, drilling) leaving seismic activity as a likely source. Undersea cables are responsible for about 99% of intercontinental traffic. As we're all thinking "path diversity," we need to also consider the viability of alternate options, both bandwidth and latency. Remember when we thought we could fail over from a T3 to a T1 - until we did? Same idea with satellite - it may not be viable. Document how you're implementing your redundant connection, including path, bandwidth and latency, and then, in a possibly resume enhancing move, schedule failovers to verify it's viable, or at least tolerable.

Usual reminder that we learned to have backup power for data centers, backup internet connectivity also needed these days. But, a twist here: network connectivity for many applications these days need lower latency than satellite service can provide – bandwidth alone is not the issue. Some “crown jewel” business processes may require more expensive dedicated backup services, both for on premise hosted and cloud hosted.

Undersea cables are the weakest link on the Internet. If they are damaged, the result is a service degradation until alternate communication paths can be established. Unfortunately, there isn’t a lot of redundancy on the Internet especially it’s outer edges.

While NIST is working to bridge the gap on enrichment, they are also dealing with the first budget cut in over 10 years, as well as a doubling of published CVEs comparing 2017 to 2023. One hopes the consortium they are establishing will help bridge both resource and volume challenges.

The lesson for the rest of us, here and in the case of the recent AT&T wireless outage, is that changes to processes should be planned in such a way that they do not put the mission at risk.

NIST has certainly gotten everyone’s attention regarding the state of the NVD. What would be helpful is a bit more transparency on the makeup of this consortium and possible changes to the data that makes up the NVD. NIST helped create the demand for the NVD, and it should resource it while it forms the consortium.

The exploit for the flaw is trivial. I have not seen any attempts against our honeypots yet, but due to the simple exploit, and attackers ability to easily enumerate vulnerable devices: Assume compromise when patching.

CVE-2024-25153, directory traversal flaw, CVSS score of 9.8, allows a file to be uploaded outside the intended "uploadtemp" directory, then executed. The fix is to upgrade to FileCatalyst 5.1.6 Build 114 or higher, which also resolves two other flaws, CVE-2024-25154 and CVE-2024-25155, which can be used for information leakage and code execution. The researcher from LRQA Nettitude not only discovered the vulnerability but also released a POC exploit. Given the attention on file transfer system weaknesses, by folks like the Cl0p ransomware gang, you need to get the updates deployed post haste.

The McDonald’s Global CIO message had a telling quote: “Notably, this issue was not directly caused by a cybersecurity event; rather, it was caused by a third-party provider during a configuration change.” Which is like saying “Notably, arsonists didn’t burn down my house, that electrician we used caused the fire. But, we are still sleeping in a tent.” We really need CIOs that think of security as just an attribute of reliability and service levels vs. some totally separate effort.

Third-parties are how we're getting business done, and the impacts of errant configuration changes are widely felt. Remember the AT&T outage last month? Make sure you understand where you have third parties and what the impact of service outages would be. Remember when you're down, pointing to the third-party isn't going to satisfy your customers; they want to know when services will be restored. Work with your third parties to understand their processes, to include fail-over and reporting, and make sure they are commensurate with the risks of service impacts to your business.

The implication of third parties in breaches, starting with Target and including this one, raises three questions. First, does your reliance on a third party constitute a single point of failure for your enterprise? Second, does your connection to a third party materially increase your attack surface? Third, are third parties restricted to only that portion of the enterprise network to which they must have access for the intended purpose? Consider that I may have the order wrong.

This event happened on February 16th, and the compromised accounts appear to be regular users, not top leadership, which would allow attackers to nominally insert themselves into the business communication, possibly leveraging that access for gains later. Here is a good excuse for making sure you've not got gaps in your email MFA configuration, no special exceptions, and that your session token life is within risk tolerance and documented.

Strong authentication (at least two kinds of evidence, at least one of which is resistant to replay), is essential for e-mail.