CISA Vulnerability Review 2024-2025; NCSC: Hackers are Exploiting Exposed OT; Project Watershed 250

It's really easy to get distracted by the new shiny things and overlook the basics. Apply updates in a timely fashion, don't expose management interfaces or OT to the Internet, use strong, phishing-resistant MFA (relentlessly), change default credentials, monitor, alert, etc. It doesn't take AI to find an exposed vulnerable service with a compromised or default credential. Spin up a team to help your developers not only create secure code but also implement needed defenses on their code repositories and necessary processes to ensure the packages they leverage are also genuine and secure.

CISA’s description of this report as a baseline from "prior to widespread AI-enabled vulnerability discovery" really got my attention. It's good to have that baseline for historical purposes, because vulnerability discovery is accelerating dramatically, with AI becoming an increasingly important driver. The report also rings true from what my team sees in our penetration testing, especially the frustrating continuing existence of XSS and SQLi flaws. Secure by Design needs to reduce the number of these vulnerabilities we create in the first place, while organizations also need to rethink their vulnerability-management processes. Building a VulnOps capability can help defenders absorb the growing discovery and remediation load.

One thing to highlight here is XSS. Most companies will not necessarily address XSS, because its impact has not demonstrated widespread exploitation to many people. When we see more payloads that start with XSS and end in something very destructive, like ransomware, we will see more companies address it. I tend to agree that most companies we test do not have basic security locked down, and sometimes it takes them years to address issues.

CISA's two-year look-back validates what we've known since the Director introduced "Secure by Design": the root causes haven't fundamentally changed. Even with more than 375 companies signing on, real-world progress feels stalled. While we wait for tech vendors to fully own customer security outcomes, the real priority today is automating your patch management so you aren't left exposed.

I think the headline finding of this report is correct and must be repeated more often: "Organizations must shift from reacting to threat actors to fixing the fundamental flaws those actors exploit." We tend to chase squirrels and leave the front door unlocked. The art of good cyber security leadership is to balance both: Keep in touch with recent developments, and manage the boring part of cybersecurity operations. In the past, whenever an emergency patch was released, as part of our StormCenter data we were often able to identify three distinct phases: (1) Immediate patching, often less than a week; (2) Patching on some kind of schedule, usually around one month; and (3) "The Rest," usually around 10-20% of affected systems, who will never get patched and only fade away years later after the systems fail and are replaced.

It is good to see updated data, but we know that well-understood, "Unsafe at Any Speed" software vulnerabilities continue to show up in new production code or get discovered in older deployed software for years. We need more analysis about (a) why this continues, and (b) why software vulnerability test/QA processes continue to let them through. I'd hoped the Cyber Safety Review Board (modeled after the Transportation Safety Review Board) would be driving that progress, but the CSRB was shut down in early 2025. Hopefully the various industry coalitions working together to improve open-source software and AI-related security focus will make progress here.

Amen!

An important point in this advisory is that organizations should verify that their OT is not exposed to the Internet rather than simply assuming it is not. Legacy connections, configuration changes, and forgotten remote access can make the running network very different from the network diagram or design. The recommendation to prevent remote programming of controllers during normal operations is equally important. If a PLC does not need to accept programming changes, engineering the system so that it cannot accept them removes an attack path.

The most important line in this advisory is the instruction not to assume your OT is not internet-facing. Exposure is almost never an intentional decision someone made and approved; it's often an artifact of vendor remote support, troubleshooting, a lack of monitoring on the systems, or a legacy HMI with no current owner. Also, note the order of NCSC's eight actions: Building the architecture view and verifying exposure come first, and that is correct, because you cannot harden a boundary or segment a network you cannot see. It sometimes feels hopeless to continue begging for these essential capabilities like MFA and asset management, because they sound simple, yet they still go unmet. If you do one thing this week, scan your own address space from the outside the way an adversary would, then cross-reference the results against your asset inventory. There's a good chance the adversary has a clearer inventory of your estate than you do, and the gap between those two lists is your work queue.

I'd add _convenience_ and _pressure to deliver_ to the list of possible reasons OT systems are found exposed to the Internet. Whatever the reason, offer amnesty for discovery and reporting, and aid the cleanup. There is a chance they have a use case which fits the OT system that is not in your regular IT environments; you'll need to work together on resolution. Don't forget: In OT, availability is king, so planned changes, including updates, may need a bit of fineness to orchestrate.

Great move by the NCSC to drop this advisory. Given the recent spike in OT attacks — from US water facilities and Poland's energy grid to UK automotive plants — the timing couldn't be better. The recommended mitigations are spot-on and reaffirm well-known best practices. The hard part, as always, will be turning those recommendations into actual implementation on the ground.

Project Watershed 250 represents an important change in how we approach cybersecurity for small water utilities. I am hoping that the six-month effort identifies capabilities that can be standardized, shared, and scaled to thousands of utilities nationwide. This has the potential to develop a security model applicable to all utilities, not just those in Texas.

Well, that was fast! In Friday's edition of NewsBites, Melissa Bischoping argued that small water utilities need something like a "Civil Air Patrol, but for cyber": people who can actually help these organizations implement, monitor, and harden their systems. Three days later, along comes Project Watershed 250. It isn't exactly the same model, but it is very much in the same spirit. This will bring expertise and technology directly to utilities that may not have enough of either on their own. I especially like that this is a six-month pilot designed to find out what works. Measure the results, publish the lessons, and scale the things that actually help.

Hey, didn't we just talk about this? As Ed pointed out, I discussed this in last week's NewsBites, so I'm happy to see the discussion continue. I do want to point out, however, that six months of donated vendor time is not the same thing as durable capability at utilities that will still be understaffed at the end. Donated vendor time is also often seen as a marketing opportunity; what value will these organizations gain from tooling, and will it be something they can sustain after the 6 months? When this pilot wraps, we need to see discussion and lessons learned: what did they find, how much of it was fixable inside the utility's existing budget and headcount, and who runs the monitoring on day 181? In the meantime, if you run a small utility outside Texas, do not wait for a program to reach you. There are still no-cost services at CISA that you can leverage today, or you can reach out to your state representatives to start the conversation about a similar initiative.

I'd like to see 49 copies of this project. This pilot is funded by the private sector partners, which means the water service providers can opt in without having to find the money for cybersecurity tools. If you're a water utility in Texas, get signed up, even if you're sure you've got your bases covered; having that verified will be well worth it.

Most of the things that need to be done to secure our water systems fall into what we call basic hygiene, things well-known and easy to do. Unfortunately the rest includes undoing things that never should have been done in the first place, such as connecting OT controls to the public networks (without strong authentication and application layer encryption). The CAP analogy is apt.

Great to see the administration rolling out Watershed 250. It definitely brings to mind past efforts like the '100-Day Sprint' and the Water Sector Cybersecurity Task Force. Here's hoping it breaks the pattern this time, moving well beyond a temporary pilot and securing the sustained federal funding required for lasting impact.

These types of Public/Private partnerships are going to be critical to help infrastructure get more secure. I am glad we are seeing some movement on this, because it will affect people, and it’s going to be important.

I've been saying privately to folks for a year or two now that ServiceNow is one of those sleeper products that are so embedded in organizations that when someone finds a critical bug, it may be really bad. This tool is great for automation and integration into processes, but it's also not considered a Tier0 asset. It really should be. If you are running ServiceNow, I recommend you make sure to really harden that product because of how much automation and integration into core businesses I've seen. It can be used to add users to AD Groups and change firewall rules, so you can imagine how much access these systems have.

If you're self-hosting the ServiceNow AI Platform, you've got homework. ServiceNow had not detected any exploitation of the flaws when the updates were released (yay), but expect adversaries will be working as hard as possible to reverse-engineer the fixes; there is no prize for second place in this race. This is also a good time to get to the most current ServiceNow platform, Australia, before Brazil is released later this year.

Three unauthenticated CVSS 10.0 flaws in a platform that by design holds privileged integration credentials to most of your environment. Whatever your crown jewels list looks like, ITSM probably belongs on it, because the CMDB and the service account fan-out put a map and a key in the same place. If you're self-hosting, you should do two things: 1) Patch without delay ('unauthenticated is the word that should compress your timeline'); 2) Go looking for evidence instead of assuming — review web logs and outbound connections. Search your HTTP access logs for anomalous requests and unusual payloads/payload sizes. Check your database logs for high frequencies or clusters of errors in statements that might indicate attempts at SQL injection.

The SolarWinds attack in 2019 highlighted that system management platforms are often given complete access and are high value targets. If you use ServiceNow, prioritize patching and reviewing configurations for best practices.

Given the quality of the software in the marketplace, patch early, patch often, patch late.

As I am writing this, Papercut just released emergency patch #3, which is still not considered "final." Do as much as you can to isolate affected systems. Papercut has published indicators of compromise. A public exploit was released this weekend.

PaperCut is printer management software. If you've hired a company to manage/service your printers, you may have it in your environment, even if your team has never heard of it. This is a good time to find out how your printers are managed, if you don't already know. Beyond applying the updates, make sure that only authorized devices are able to access whatever you're using to manage your printers, and like any other management interface, don't expose it to the Internet.

PaperCut NG may be a relevant software package to many companies, but it's not ubiquitous. That puts them in an interesting category. It's probably relevant enough that people absolutely need to patch, but since you don't see it everywhere, it may not hit people's radar as to how relevant it is. This is one of those outreach programs to make sure people patch.

Ouch! It's been a rough couple of weeks for PaperCut, and I'm doing my darnedest to avoid a cheap pun based on their name. But I do want to give PaperCut some credit for how this unfolded. During active exploitation, outside researchers kept digging, the vendor kept listening, and a second emergency release added hardening beyond the first. A second emergency patch isn't necessarily evidence that the first response failed… sometimes it's evidence that the response is still working.

This is an interesting path in the LLM space for the DSA, not only as it applies to prompt injection bypassing guardrails, but also the prospect of pruning training data to comply with requirement to remove illegal data. Couple that with the EU starting to enforce their new AI act, overlaying claims from Washington that the EU is unfairly targeting US companies, and ice the cake with a December deadline… this will be interesting to watch. Apparently, X's AI chatbot Grok is already going through this process. Don't panic, watch for announcements on service changes, and steer clear of the politics. If you're delivering services to the EU, you should be looking at what the DSA means to you, and plan accordingly, before you cross this threshold.

Crossing this user growth threshold is a double-edged sword. While rapid expansion is a major win, surpassing 45 million active EU users triggers automatic designation as a VLOP or VLOSE under the DSA. The resulting compliance burden for these companies is extensive, and many view the strict oversight, heavy auditing requirements, and massive potential fines as less about safety and more about generating revenue for the EU. Time will tell.

In a global economy, the EU continuing to raise the bar to reduce consumer risk online is a good thing. Not fast moving but going in the right direction, just as automotive/highway safety regulations did — which in the US was in 1966, about 50 years after mass production of cars began!

While I think the VLOP/VLOSE designation is helpful, almost all enterprise connections to the public networks become part of our cyber and economic infrastructure. Their risks are our risks.

Berlin's refusal to pay is admirable, but the important work happens before the ransom note arrives. Organizations should decide in advance who has authority to make payment decisions, what legal, ethical, and business considerations govern them, and how they will operate if the answer is no. An attacker-controlled countdown clock is a terrible time to invent your ransomware policy. If you haven't thought through and documented your ransomware playbook, now's the time to do so.

Do you have your ransomware playbook all set? Have you re-factored it for the more current exfiltration/extortion without encryption scenario? As Ed said, don't wait for the attack to start that process. While you're at it, check with legal and your financial institution to make sure you fully understand the legal nuances of any scenario involving payment. Lastly, make sure that any resources you're planning to enlist to support your response are dialed in: points-of-contact and contact methods verified, and contracts on standby. Your future self will thank you.

Unfortunately there is not enough data to definitively say whether ever paying a ransom is the right business choice. However, if you do a realistic tabletop exercise with management/boards in advance, your company will be able to make the right decision if it comes to that. One key point: Paying off may reduce or eliminate business disruption costs, but it will *not* fund the investigation/analysis/improvements needed to ensure it does not happen again. In that tabletop exercise, choose a scenario where the incident is based on a weakness for which you need support in making proactive improvements.

Kudos to Berlin for standing firm and refusing to pay the ransom. Baltimore took a similar stance during a 2019 attack, rejecting a demand of roughly 13 Bitcoin (worth around $100,000 at the time). While that choice spared the city from funding cybercriminals, manually rebuilding its IT infrastructure ultimately cost over $18 million in recovery efforts, system upgrades, and lost revenue. Public opinion on the decision was deeply divided, highlighting why every organization needs a tested ransomware incident response playbook ready to deploy.

We fight as we train as we fight. It is nigh impossible to even identify the tactics after the battle is engaged.

Reads like something out of a spy novel, doesn't it? This reminds me of the briefing when I first had a clearance; I seem to recall the term Leavenworth liberally used in the consequences part of the discussion. One comment Laatsch made was that it would not be hard for him to avoid mistakes made by people under investigation, indicating he felt the controls could be easily bypassed, and he would avoid detection. My point here is to watch for that sort of feedback on your security controls and follow up on it. This is not only a chance to improve ineffective controls, but also a chance to address a control which is being worked around (and is therefore "dumb") to accomplish needed business practices.

There is some painful irony in an employee of the Insider Threat Division becoming the insider threat. More importantly, insider-risk controls have to apply to the people who build, administer, and monitor those controls too. Security personnel are not outside the threat model.