CISA

What Is Wastewater? How Is It Treated? - Chemtech International

Hello All. In my experience, when most municipalities talk about their “Crown Jewels,” the conversation usually focuses on data and traditional IT systems: citizen information, financial systems, email, Active Directory, tax systems and emergency services data. Those systems are important, but the recent cyberattacks against water utilities in Minnesota should force municipalities to think more broadly about what their Crown Jewels really are.

In late July, a coordinated cyberattack targeted operational technology (OT) at more than 30 community water systems across Minnesota. While the operational impact appears to have been limited, the incidents highlight a problem that has existed within municipalities for years: many of the systems responsible for delivering essential physical services remain outside the traditional cybersecurity conversation.

Municipalities operate a surprising amount of OT. Beyond water and wastewater, cities may operate traffic management systems, building automation, physical access control, transit infrastructure, emergency power and environmental controls. Behind these services are PLCs, RTUs, HMIs, SCADA platforms, engineering workstations and communications networks that may have been installed over decades by different departments, vendors and contractors.

Yet when organizations conduct cyber risk assessments or identify their most critical assets, many of these systems are still overlooked. I still remember the discussion, “Bob, our engineer manages water, why would we worry about that?”

Rethinking the Crown Jewels

Traditional Crown Jewel exercises tend to focus on information: what data can we not afford to lose, disclose or have altered? In an OT environment, that question needs to be expanded. Municipalities also need to ask what physical services they cannot afford to lose control of and what technology is necessary to safely deliver those services.

A PLC controlling a pump may contain almost no sensitive information. From a traditional information-classification perspective, it might appear relatively unimportant. But if losing control of that PLC means losing water pressure to thousands of residents or interrupting wastewater treatment, its importance looks very different.

The value of an OT asset often isn’t the information stored on it. It’s the physical process it controls.

This is why OT risk needs to be evaluated differently. Compromising systems responsible for water pressure, chemical treatment, electrical distribution or traffic control can create consequences that extend beyond cybersecurity into operations, the environment and potentially public safety.

This Is Bigger Than Water

It would be easy to look at Minnesota and treat this as a water-sector problem. The same conditions, however, exist across municipal infrastructure.

A municipality may have hundreds or thousands of connected devices distributed across facilities and departments, some operating for fifteen or twenty years. There may be legacy operating systems, vendor remote access, shared credentials, weak segmentation and systems with direct or indirect Internet connectivity. In some cases, the cybersecurity team may not even know these environments exist.

Before talking about advanced monitoring or sophisticated OT security tooling, municipalities need to understand what they actually operate, how it is connected and which systems support critical services.

Start With the Service, Not the Technology

When organizations begin addressing OT cybersecurity, there is often a temptation to immediately start discussing technology: OT monitoring platforms, firewalls, passive network monitoring and other security products. Those may eventually be part of the answer, but they shouldn’t be the starting point.

For a water utility, the Crown Jewel isn’t necessarily the SCADA server. It may actually be the municipality’s ability to safely treat and distribute drinking water. The SCADA servers, PLCs, engineering workstations, communications infrastructure and remote-access systems are technologies that enable that mission.

Thinking this way moves cybersecurity away from simply protecting devices and toward protecting the delivery of critical services.

Understanding the Actual Risk

Once those critical services and dependencies are identified, municipalities can start asking better questions. Do we know every device involved in delivering the service? Which systems can communicate with the Internet? Who can remotely access the environment? Do vendors still have unnecessary accounts? Can corporate IT systems communicate directly with OT? Would anyone know if PLC logic or controller configurations were modified?

Recovery is equally important. If SCADA became unavailable tomorrow, could operators continue running the process? Are known-good copies of controller logic and configurations available? Have backups actually been tested? Does the incident response plan address OT, or does it assume affected systems can simply be isolated and reimaged like traditional IT?

Perhaps the simplest question is also one of the most important: if someone compromised one of these systems at 2:00 a.m., how would we know?

Start With the Fundamentals

Smaller municipalities and utilities obviously don’t have Fortune 500 cybersecurity budgets, and the answer isn’t to build a multimillion-dollar OT security program. It is to prioritize based on risk.

Start by knowing what assets exist, understanding network architecture and connectivity, reviewing remote access, eliminating unnecessary Internet exposure, removing default credentials, improving segmentation and maintaining known-good backups. Incident response plans also need to account for the operational realities of OT.

Technologies such as passive OT monitoring (which, to have some visibility, doesn’t have to be a costly commercial platform), centralized logging and specialized OT security platforms can then provide significant value, but the technology should support the risk strategy rather than define it.

Cybersecurity teams also need to get outside the data centre. They need to walk through water plants, pumping stations and traffic operations centres, talk with operators and engineers, and understand how vendors maintain these environments. They need to understand what actually happens when an operator clicks a button on an HMI and a pump, valve or other physical device responds somewhere else.

The Real Lesson From Minnesota

The Minnesota incidents are important not because they demonstrate some revolutionary new attack technique, but because they show how exposed even relatively small communities can become. A municipality doesn’t need to be a major city to become a cyber target. Once infrastructure is connected or remotely accessible, organizational size provides very little protection.

Attackers don’t care that a municipality has a small IT department, that a PLC was installed fifteen years ago or that cybersecurity wasn’t included in the original capital budget.

Municipalities need to broaden how they think about their Crown Jewels. Protecting citizen information, financial systems and identities remains critical, but the risk conversation also needs to include the controllers, SCADA platforms, engineering workstations, networks and remote connections that keep physical services operating.

The question is no longer simply whether someone could steal municipal data. Municipalities also need to ask whether a cyberattack could interfere with their ability to safely deliver the services their communities depend on.

The incidents in Minnesota are another reminder that some of a municipality’s most important Crown Jewels may not be sitting in the data centre at all.

Read more

The U.S. government has unveiled new security guidelines aimed at bolstering critical infrastructure against artificial intelligence (AI)-related threats.

“These guidelines are informed by the whole-of-government effort to assess AI risks across all sixteen critical infrastructure sectors, and address threats both to and from, and involving AI systems,” the Department of Homeland Security (DHS) said.

In addition, the agency said it’s working to facilitate safe, responsible, and trustworthy use of the technology in a manner that does not infringe on individuals’ privacy, civil rights, and civil liberties.

The new guidance concerns the use of AI to augment and scale attacks on critical infrastructure, adversarial manipulation of AI systems, and shortcomings in such tools that could result in unintended consequences, necessitating the need for transparency and secure by design practices to evaluate and mitigate AI risks.

Specifically, this spans four different functions such as govern, map, measure, and manage all through the AI lifecycle –

  • Establish an organizational culture of AI risk management
  • Understand your individual AI use context and risk profile
  • Develop systems to assess, analyze, and track AI risks
  • Prioritize and act upon AI risks to safety and security

“Critical infrastructure owners and operators should account for their own sector-specific and context-specific use of AI when assessing AI risks and selecting appropriate mitigations,” the agency said.

“Critical infrastructure owners and operators should understand where these dependencies on AI vendors exist and work to share and delineate mitigation responsibilities accordingly.”

The development arrives weeks after the Five Eyes (FVEY) intelligence alliance comprising Australia, Canada, New Zealand, the U.K., and the U.S. released a cybersecurity information sheet noting the careful setup and configuration required for deploying AI systems.

“The rapid adoption, deployment, and use of AI capabilities can make them highly valuable targets for malicious cyber actors,” the governments said.

“Actors, who have historically used data theft of sensitive information and intellectual property to advance their interests, may seek to co-opt deployed AI systems and apply them to malicious ends.”

The recommended best practices include taking steps to secure the deployment environment, review the source of AI models and supply chain security, ensure a robust deployment environment architecture, harden deployment environment configurations, validate the AI system to ensure its integrity, protect model weights, enforce strict access controls, conduct external audits, and implement robust logging.

The briefing by the NSA can be found here – https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3741371/nsa-publishes-guidance-for-strengthening-ai-system-security/

The full report can be found here – https://media.defense.gov/2024/Apr/15/2003439257/-1/-1/0/CSI-DEPLOYING-AI-SYSTEMS-SECURELY.PDF

Read more