The voluntary recommendations from the Department of Homeland Security cover how artificial intelligence should be used in the power grid, water system, air travel network, healthcare, and other pieces of critical infrastructure.

Source: GK Images via Alamy Stock Photo

The US Department of Homeland Security (DHS) has released recommendations that outline how to securely develop and deploy artificial intelligence (AI) in critical infrastructure. The recommendations apply to all players in the AI supply chain, starting with cloud and compute infrastructure providers, to AI developers, and all the way to critical infrastructure owners and operators. Recommendations for civil society and public-sector organizations are also provided.

The voluntary recommendations in "Roles and Responsibilities Framework for Artificial Intelligence in Critical Infrastructure" look at each of the roles across five key areas: securing environments, driving responsible model and system design, implementing data governance, ensuring safe and secure deployment, and monitoring performance and impact. There are also technical and process recommendations to enhance the safety, security, and trustworthiness of AI systems.

AI is already being used for resilience and risk mitigation across sectors, DHS said in a release, such as AI applications for earthquake detection, stabilizing power grids, and sorting mail.

The framework looks at each role's responsibilities:

*   Cloud and compute infrastructure providers need to vet their hardware and software supply chain, implement strong access management, and protect the physical security of data centers powering AI systems. The framework also has recommendations on supporting downstream customers and processes by monitoring for anomalous activity and establishing clear processes for reporting suspicious and harmful activities.
    
*   AI developers should adopt a secure by design approach, evaluate dangerous capabilities of AI models, and "ensure model alignment with human-centric values." The framework further encourages AI developers to implement strong privacy practices; conduct evaluations that test for possible biases, failure modes, and vulnerabilities; and support independent assessments for models that present heightened risks to critical infrastructure systems and their consumers.
    
*   Critical infrastructure owners and operators should deploy AI systems securely, including maintaining strong cybersecurity practices that account for AI-related risks, protecting customer data when fine-tuning AI products, and providing meaningful transparency regarding their use of AI to provide goods, services, or benefits to the public.
    
*   Civil society, including universities, research institutions, and consumer advocates engaged on issues of AI safety and security, should continue working on standards development alongside government and industry, as well as research on AI evaluations that considers critical infrastructure use cases.
    
*   Public sector entities, including federal, state, local, tribal, and territorial governments, should advance standards of practice for AI safety and security through statutory and regulatory action.
    

"The framework, if widely adopted, will go a long way to better ensure the safety and security of critical services that deliver clean water, consistent power, Internet access, and more," said DHS secretary Alejandro N. Mayorkas, in a statement.

The DHS framework proposes a model of shared and separate responsibilities for the safe and secure use of AI in critical infrastructure. It also relies on existing risk frameworks to enable entities to evaluate whether using AI for certain systems or applications carries severe risks that could cause harm.

"We intend the framework to be, frankly, a living document and to change as developments in the industry change as well," Mayorkas said during a media call.

DHS Releases Secure AI Framework for Critical Infrastructure

Now that large language models (LLMs) and LLM systems are flourishing, it’s important to reflect upon their security, the risks affecting them and the security controls to reduce these risks to acceptable levels.First of all, let’s differentiate between LLMs and LLM systems. This difference is key when analyzing the risks and the countermeasures that need to be applied. An LLM is an algorithm designed to analyze data, identify patterns and make predictions based on that data. A LLM system is a piece of software composed of artificial intelligence (AI) components, which includes a LLM along

Now that large language models (LLMs) and LLM systems are flourishing, it’s important to reflect upon their security, the risks affecting them and the security controls to reduce these risks to acceptable levels.

First of all, let’s differentiate between LLMs and LLM systems. This difference is key when analyzing the risks and the countermeasures that need to be applied. An LLM is an algorithm designed to analyze data, identify patterns and make predictions based on that data. A LLM system is a piece of software composed of artificial intelligence (AI) components, which includes a LLM along with non-AI components.

**Security considerations for LLM**

As a specialized algorithm for analyzing data, identifying patterns and making predictions based on that data, a LLM's composition and data flow is relatively simple. Although there are exceptions, when you download a model from a model repository, most of the time you've downloaded a definition of that model and its weights. The weights are just arrays of numbers that define the configuration of the model. The definition and weights are later loaded by the inference software to serve the model. During inference, it's possible to send bytes, such as strings, images and sounds to the model, which are read by its input layer. The model processes the bytes and returns other bytes through its output layer.

From a security point of view, a model is basic with a small attack surface. The only interaction point is the LLM input layer. It's possible that a vulnerability can be triggered in the LLM by a specially crafted input, but if the model is built securely based on its definition, and its weights are loaded securely, the probability is low. The weights for the first open models were provided as Python pickle objects. This kind of Python object can execute commands when they are loaded. This behavior made incidents like the "Sleepy Pickle" exploit subtly poisoning ML models possible. Model repositories made the decision that safer mechanisms should be used to distribute weights. Nowadays, safetensors have become the standard format to safely store them.

Due to the small attack surface of LLMs, when we analyze the security of a LLM application, it's wise to focus on the LLM system as a whole rather than individual models.

**The case of prompt injections**

Prompt injection issues are intrinsic to the nature of a LLM and they cannot be fully fixed. They cannot be treated as regular security vulnerabilities because they cannot be patched. However, it’s crucial to note that a prompt injection can trigger a security vulnerability in a LLM system. Even if a LLM has been specifically trained to be safe and to always follow its original instructions, it’s always possible to circumvent any restriction taught to the LLM, imposed in the context or injected in the prompt. We should always consider that a LLM could return unsafe outputs, and we should treat them as untrusted until validated.

A prompt injection issue in a LLM may imply a security vulnerability in a LLM system.

**The complexity of LLM systems**

A LLM system is a piece of software composed of AI components, including LLMs and non-AI components. In a LLM system, the output of a LLM might be returned directly to the user, or it might be used as input for another component. A LLM system should treat the output of a LLM as untrusted. This does not mean that the output of a LLM is not useful, but that it should be post-processed depending on how the system needs to use it. If a LLM system uses the output of a LLM, and that negatively impacts confidentiality, integrity or availability, then it creates a security vulnerability.

For example, suppose that a LLM generates vulnerable code, and that code is compiled and executed to perform a task, such as generating a diagram. You must assume that there is always the possibility that the code generated by the LLM has defects or security issues. The probability of that occurring cannot be reduced to zero due to the non-deterministic nature of a LLM. The best approach to reduce this risk is to design a post-process mechanism. For example, you might execute the code in a sandbox and then analyze it or run static security analysis tools on the generated code. This is why a strong AI platform that allows for the design of machine learning (ML) pipelines is essential for enterprise LLM system deployments.

**Measurement and benchmarking**

Model safety is important to the overall security of a LLM system. A safety issue in a model, such as prompt injection, can cause a security vulnerability in the LLM system. The safer a model is, the better the security of the LLM system.

When you select a LLM for your LLM system, you need to be aware of how safe it is. Currently, the most common approach to measure the safety of a LLM is to ask the model several specially crafted questions and evaluate how it responds.

When measuring how safe an open answer from the LLM is, you can have the response reviewed by humans or by automation such as another LLM specially trained for this task. Alternatively, you can request that the LLM responds in a specific format that can be parsed by regex. For example, you might request the LLM to respond with "yes" or "no", and depending on the output, conclude whether or not the response is safe. Each approach has advantages and disadvantages and should be properly evaluated for your specific use case, but that is out of  scope for this article.

The same way you have unit tests, integration tests and e2e tests in the development pipelines of regular software, you should have automatic safety evaluation of any models you use in your LLM software.

There are open source solutions that already include well known datasets to evaluate the safety of LLM models. For example, lm-evaluation-harness is being integrated with TrustyAI.

**Guardrails**

Currently, no one can guarantee that a LLM will provide safe responses. If you need to trust the output of an LLM, you must validate that output first. Software providing runtime guardrails is increasingly being included (ideally provided by the AI platform) as a component of a LLM system. Guardrails read the input and output of the LLM, and process it before it's dispatched to the next component of the system. Guardrails software has the capability of processing the input or output in different ways. For example, when analyzing input, it can try to detect whether the prompt is malicious or trying to exploit a prompt injection. When a guardrails component is analyzing the output of a LLM, it can try to identify whether the output is unsafe and can even modify, block, log it and raise an alarm.

There are some open source guardrails solutions like Guardrails AI and NeMo-Guardrails. The community project TrustyAI provides a solution for guardrails during training and is already exploring the development of runtime guardrails functionality. IBM has released the granite-guardian models, which are a collection of models specifically designed to detect risks in prompts and responses.

**Next steps**

When analyzing the security of a LLM and LLM systems, you must take into account the limitations of LLMs and focus your analysis on the LLM system as a whole. Always treat the output of an LLM as tainted, and evaluate whether you need to validate its output before providing it to the user. This is especially important when that output is intended as the input of another component. Contribute to and leverage models such as granite-guardian and open source tools such as lm-evaluation-harness to measure and benchmark the safety of LLMs, and use TrustyAI to process input and output of LLMs to shape the future of LLM and AI security and safety.

Security of LLMs and LLM systems: Key risks and safeguards

Plus: An “AI granny” is wasting scammers’ time, a lawsuit goes after spyware-maker NSO Group’s executives, and North Korea–linked hackers take a crack at macOS malware.

In perhaps the most adorable hacker story of the year, a trio of technologists in India found an innovative way to circumvent Apple’s location restrictions on AirPod Pro 2s so they could enable the earbuds’ hearing aid feature for their grandmas. The hack involved a homemade Faraday cage, a microwave, and a lot of trial and error.

On the other end of the tech-advancements spectrum, the US military is currently testing an AI-enabled machine gun that is capable of auto-targeting swarms of drones. The Bullfrog, built by Allen Control Systems, is one of several advanced weapons technologies in the works to combat the growing threat of cheap, small drones on the battlefield.

The US Department of Justice announced this week that an 18-year-old from California has admitted to making or orchestrating more than 375 swatting attacks across the United States.

Then, of course, there’s the Donald Trump of it all. This week, we published a practical guide to protecting yourself from government surveillance. WIRED has covered the dangers of government surveillance for decades, of course. But when the president-elect is explicitly threatening to jail his political enemies—whoever that may be—now’s probably a good time to brush up on your digital best practices.

In addition to potential dragnet surveillance of US citizens, US Immigration and Customs Enforcement started ramping up its surveillance arsenal the day after Trump won reelection. Meanwhile, experts are expecting the incoming administration to roll back cybersecurity rules instituted under president Joe Biden while taking a harder line against adversarial state-sponsored hackers. And if all this political upheaval has you in the mood to protest, beware: An investigation copublished by WIRED and The Marshall Project found that mask bans instituted in several states add a complicated new layer to exercising freedom of speech.

And that’s not all. Each week, we round up the privacy and security news we didn’t cover in depth ourselves. Click the headlines to read the full stories, and stay safe out there.

In August 2016, approximately 120,000 bitcoin—at the time worth around $71 million—were stolen in a hack on the Bitfinex cryptocurrency exchange. Then in 2022, as the value of cryptocurrency had rocketed skywards, law enforcement officials in New York arrested husband and wife Ilya Lichtenstein and Heather Morgan in relation to the hack and laundering the much-inflated $4.5 billion of stolen cryptocurrency. (At the time, $3.6 billion of the funds were recouped by law enforcement investigators.)

This week, after pleading guilty in 2023, Lichtenstein was sentenced to five years of jail time for conducting the hack and laundering the profits. With subsequent cryptocurrency spikes and additional seizures related to the hack, the US government has now been able to recover more than $10 billion in assets. A series of operational security failures by Lichtenstein made much of the illicit cryptocurrency easy for officials to seize, but investigators also applied sophisticated crypto-tracing methods to unpick how the funds had been stolen and subsequently moved around.

Aside from the brazen scale of the heist, Lichtenstein and Morgan gained online prominence and ridicule after their arrests due to a series of Forbes articles written by Morgan and rap videos posted to YouTube under the name of “Razzlekhan.” Morgan, who also pleaded guilty, is due to be sentenced on November 18.

**An ‘AI Granny’ Is Wasting Phone Scammers’ Time**

Scammers are increasingly adopting AI as part of their criminal toolkits—using the technology to create deepfakes, translate scripts, and make their operations more efficient. But artificial intelligence is also being turned against the scammers. British telecoms firm Virgin Media and its mobile operator O2 have created a new “AI granny” that can answer phone calls from scammers and keep them talking. The system uses different AI models, according to The Register, that listen to what a scammer says and respond immediately. In one case, the company says it kept a scammer on the line for 40 minutes and has fed others fake personal information. Unfortunately, the system (at least at the moment) can’t directly answer calls made to your phone; instead, O2 created a specific phone number for the system, which the company says it has managed to get placed in lists of numbers that scammers call.

**Alleged NSO Group Spyware Victim Adds NSO Founders and Executive to Lawsuit**

In a new legal strategy for those attempting to hold commercial spyware vendors responsible, lawyer Andreu Van den Eynde, who was allegedly hacked with NSO Group spyware, is directly accusing two of the company’s founders, Omri Lavie and Shalev Hulio, and one of its executives, Yuval Somekh, of hacking crimes in a lawsuit. The Barcelona-based human rights nonprofit Iridia announced this week that it filed the complaint in a Catalan court. Van den Eynde was reportedly a victim of a hacking campaign that used NSO’s notorious Pegasus spyware against at least 65 Catalans. Van den Eynde and Iridia originally sued NSO Group in a Barcelona court in 2022 along with affiliates Osy Technologies and Q Cyber Technologies. “The people responsible for NSO Group have to explain their concrete activities,” a legal representative for Iridia and Van den Eynde wrote in the complaint, which was written in Catalan and translated by TechCrunch.

**North Korea-Backed Hackers Are Exploring New macOS Malware**

Research published this week by the mobile device management firm Jamf found that hackers who have been linked to North Korea have been working to implant malware inside macOS applications built with a particular open-source software development kit. The campaigns focused on cryptocurrency-related targets and involved infrastructure similar to systems that have been used by North Korea’s notorious Lazarus Group. It’s unclear if the activity resulted in actual victim compromise or if it was still in a testing phase.

Financially motivated and state-backed hackers have less occasion to use malware targeting Apple’s Mac computers than hacking tools that infect Microsoft Windows or Linux desktops and servers. So when Mac malware crops up, it’s typically a niche point, but it can also be a revealing indicator of trends and priorities among hackers.

Bitfinex Hacker Gets 5 Years for $10 Billion Bitcoin Heist

A new report from the Open Software Supply Chain Attack Reference (OSC&R) team provides a framework to reduce how much vulnerable software reaches production.

Neatsun Ziv, CEO & Co-Founder, Ox Security

November 15, 2024

5 Min Read

Source: Andrey Kryuchkov via Alamy Stock Photo

COMMENTARY

The complexity of today's software development — a mix of open source and third-party components, as well as internally developed code — has resulted in an abundance of vulnerabilities for attackers to exploit throughout the software supply chain.

We've seen the direct effects of software supply chain attacks in incidents like the MOVEit and SolarWinds breaches, revealing that no industry sector, size of company, or stage of software development is immune. According to a survey from Enterprise Strategy Group (ESG), 91% of organizations experienced at least one software supply chain security incident in 2023, and 2024 hasn't seemed any better.

Security teams are overwhelmed by the task of sorting through, assessing, and prioritizing the mitigation of tens of thousands of alerts to discern those that pose real risk from those that are benign. In 2023, a group of AppSec experts addressed this problem by launching the Open Software Supply Chain Attack Reference (OSC&R), a freely available, MITRE ATT&CK-like framework to help organizations gain a deeper understanding of their software supply chain vulnerabilities.

The OSC&R community's inaugural report, "OSC&R in the Wild: A New Look at the Most Common Software Supply Chain Exposures," offers a comprehensive analysis of the severity of vulnerabilities across the software supply kill chain. Based on a nine-month analysis of over 100 million alerts, tens of thousands of code repositories, and 140,000 real-world applications, it examines the risk to software supply chains and probes the alignment between the vulnerabilities found in the wild and the focus of AppSec teams today.

The research offers some eye-opening statistics, including that 95% of organizations have at least one high, critical, or apocalyptic risk in their software supply chain, with the average organization having nine such issues. What's more, the OSC&R data shows that many of the most common software supply chain vulnerabilities are tied to fundamental security controls, such as authentication, encryption, publicly available information in logs, and the principle of least privilege. Following are some of the most important takeaways from the report.

**1\. Watch for Run-Time Exposure**

One in five applications was found to contain high, critical, or apocalyptic runtime vulnerabilities during the execution phase of an attack. This makes them prime targets for attackers. Because the most significant software vulnerabilities tend to surface in later attack stages, it's crucial to catch issues early in the software development life cycle.

As such, AppSec and DevOps teams should aim to strengthen application runtime security. This can be accomplished by integrating continuous monitoring and real-time protection mechanisms that focus on the later stages of an attack, when the damage potential is greatest.

**2\. It's Worth Fixing Older Vulnerabilities**

While newer vulnerabilities may grab headlines, older vulnerabilities remain the most common attack vectors when it comes to supply chain security. Techniques like command injection (15.4% of applications), sensitive data in log files (12.4% of applications), and cross-site scripting (11.4% of applications) — as well as slow-burn vulnerabilities like CVE-2024-3094, which targeted the compression utility XZ Utils in major Linux distributions — still wreak havoc in unpatched systems. Attackers continue to successfully use historical tactics and techniques, showing that "old school" vulnerabilities present significant and persistent risks.

To counter these tactics and techniques and drive down the opportunity for attack, organizations should regularly review and update legacy systems and codebases to patch known vulnerabilities. Further, implementing a robust vulnerability management program that includes continuous scanning for both old and emerging threats will harden software to known risks.

**3\. Vulnerabilities That Span Multiple Attack Stages Amplify Damage**

In the OSC&R report data analysis, 36% of applications were found to be vulnerable to exploits in the initial access attack stage, with many overlapping across multiple stages of attack. Indeed, vulnerabilities in initial access stages often open the door for more severe threats, such as persistence and execution exploits.

The data underscores the need for AppSec and DevOps team to bolster defenses across all stages of the attack life cycle, not just in initial phases. Organizations should adopt multilayered security solutions that can detect and neutralize threats at various stages of the kill chain to prevent attackers from moving laterally within systems and causing widespread cyber and business damage.

**Next Steps for AppSec Teams**

One of the questions the inaugural OSC&R report sought to answer was whether what AppSec and DevOps teams focus on matched the vulnerabilities found in the wild. The data reveals that this is not yet the case. Progress is being made, but the high volume of vulnerabilities passing through the supply chain into live applications, and the large percentage of organizations that report supply chain security incidents, indicate that greater focus on proactive software security measures is needed.

In addition, organizations need to do a better job of looking systemically at both their software development processes and the attack lifecycle to identify the places most likely to be at risk. But historical data alone is not the answer. Organizations must implement the tools and processes that give them holistic visibility of their supply chain — from the build stage all the way through runtime, and including the development and testing environments, which are occasionally overlooked.

Further, it's clear that focusing on one or two stages of software development or one stage of the attack lifecycle isn't enough. Businesses must adopt a multilayered, full-lifecycle AppSec strategy — accompanied by tools that can unify all stages — to reduce the probability of attack.

Development and security teams now have a reference they can use to map their programs to known attack vectors and tactics. OSC&R, in effect, sets the foundation for operating a streamlined software security program that reduces the number of vulnerabilities that reach production, enhancing the resiliency of the organization as a whole and easing the fears of breach due to software flaws.

**About the Author**

CEO & Co-Founder, Ox Security

Neatsun Ziv is the CEO and Co-Founder of Ox Security, the end-to-end software Active ASPM Platform. Prior to that, he was the VP of Cyber Security at Check Point, where he oversaw all cyber initiatives. His team was one of the first to respond to SolarWinds, NotPetya, and other major attacks, working closely with Interpol, Local CERT, and other enforcement agencies. Neatsun is a passionate and seasoned entrepreneur with vast cybersecurity experience. He served in the IDF Cyber Intelligence Unit and is a frequent speaker at global forums, including RSA and CPX, among others. Neatsun holds a B.Sc. from Israel's Open University (honors) and an MBA from the Technion (Magna Cum Laude).

Lessons From OSC&amp;R on Protecting the Software Supply Chain

In recent years, artificial intelligence (AI) has begun revolutionizing Identity Access Management (IAM), reshaping how cybersecurity is approached in this crucial field. Leveraging AI in IAM is about tapping into its analytical capabilities to monitor access patterns and identify anomalies that could signal a potential security breach. The focus has expanded beyond merely managing human

How AI Is Transforming IAM and Identity Security

A data broker has confirmed a business contact information database containing 132.8 million records has been leaked online.

A data broker has confirmed a business contact information database containing 132.8 million records has been leaked online.

In February, 2024, a cybercriminal offered the records for sale on a data breach forum claiming the information came from pureincubation\[.\]com.

Cybercriminal offering to sell Pure Incubation data

Pure Incubation was founded in 2012, and the company later rebranded to DemandScience. DemandScience describes itself as “a leading global B2B demand generation company accelerating global growth for clients.”

DemandScience says it specializes in lead generation, content marketing, and software development offering data intelligence and marketing solutions for B2B organizations. That’s a mouthful to describe a data broker that specializes in selling aggregated public data that other companies can use in their marketing campaigns.

When contacted by BleepingComputer about the leak, DemandScience responded by email:

> “Regarding the matter referenced in your email, we have conducted a thorough internal investigation and conclude that none of our current operational systems were exploited. We also conclude that the leaked data originated from a system that has been decommissioned for approximately two years.”

It might not be a current system, but a third-party count of the data still showed around 122 million unique business email addresses. Although at some point when we all have switched jobs, it will become worthless. Maybe that’s why the cybercriminals offered to sell for $6,000.

That the company left a decommissioned system online for a criminal to find and plunder should be grounds for a hefty fine.

Despite DemandScience playing it down, the data is valuable. How else is it making money by gathering it from public records?

**What can you do?**

Any business that meets the definition of data broker must register with the California Privacy Protection Agency (CPPA) annually. The CPPA defines data brokers as businesses that consumers don’t directly interact with, but that buy and sell information about consumers from and to other businesses.

This is good news, because it offers Californians a sort of opt-out opportunity, by filling out this form: https://demandscience.com/privacy-policy-ccpa/

You can check whether your email address was included in this data breach by using Malwarebytes’ free Digital Footprint scan. Fill in the email address you’re curious about and we’ll give you a free report.

This leak also shows how important it can be to have your data removed from data brokers sites like these. To help you, Malwarebytes offers a Personal Data Remover service (US only) that can delete your information from search results, spam lists, people search sites, data brokers, and more.

 122 million people&#8217;s business contact info leaked by data broker 

As alerts pile up, the complexity can overwhelm security professionals, allowing real threats to be missed. This is where vendors must step up.

Source: Skorzewiak via Alamy Stock Photo

COMMENTARY

For most of my cybersecurity career, I worked on the vendor side, in presales capacity, helping businesses identify and address security pain points. Now, as an information security engineer, I am on the other side, engaging with security vendors. A typical sales engagement includes pre-sales, proof of concept (PoC), onboarding, and support. While PoCs are useful, the real complexity of a product is understood only when the customer is fully onboarding. 

Although customers are responsible for accurate implementation of systems, vendors must realize they play a key role in guiding them through settings to ensure optimal performance and reduced alert fatigue. 

Achieving 100% efficiency will always be an ongoing challenge, but alert fatigue remains a significant issue. Modern security systems involve multiple components, each generating alerts that require teams to collaborate. And as alerts pile up, the complexity can overwhelm security professionals, allowing real threats to be missed. This is where vendors must step up. 

**The Reality of Alert Fatigue**

Alert fatigue is not new, but the problem becomes bigger as organizations adopt more complex security solutions. These tools detect every potential anomaly, generating a flood of alerts, many of which are low-priority or false positives, obscuring critical signals. 

When faced with hundreds of alerts daily, analysts can become numb, ignoring or delaying important alerts, which leads to security breaches. Vendors currently address only part of the challenge by delivering systems that detect every possible attack are only doing half their job. However, these products alone fall short in helping companies effectively manage the alert flood, often times requiring a managed security service provider (MSSP) to bridge the gap. But they must do a better job helping companies manage the resulting flood of information. 

**Why Vendors Must Take Ownership**

It may be tempting for vendors to shift alert management to customers, but vendors create the underlying logic that generates these alerts, and therefore, they must ensure their tools enable users to respond effectively rather than overwhelming them. 

Here's how vendors need to take lead: 

1.  Smart filtering and prioritization: Vendors should design tools that prioritize high-risk alerts while suppressing noise using machine learning and contextual analytics. This reduces irrelevant notifications. 
    
2.  Automation to reduce manual work: The volume of alerts makes manual intervention impractical. Vendors should offer built-in automation for routine alerts, allowing security engineers to focus on critical ones, such as sinkholing, rate-limiting, blocking malicious IPs, or isolating suspicious files. 
    
3.  Actionable alerts with context: Vendors need to provide meaningful data with each alert, contextualizing it for the customer's environment and offering clear next steps, enabling quicker, more effective responses. 
    
4.  Continuous engagement and customization: Vendors must stay engaged with customers beyond the initial setup, helping tailor systems to meet specific needs. Regular optimization reduces unnecessary alerts and ensures critical threats are identified. 
    
5.  Feedback-based adaptive learning: Vendors should provide solutions that evolve with feedback loops, learning from customer input. False positives or low-priority alert floods should lead to system adjustments, improving accuracy over time. 
    

**The Cost of Ignoring Alert Fatigue**

If vendors fail to address alert fatigue, security teams may miss critical threats, leading to breaches. Overwhelmed staff may burn out, increasing turnover. For vendors, poor alert management can erode customer trust, leading to dissatisfaction and potential churn. 

**Needed: A Partnership for Success**

Alert fatigue is a shared problem, but vendors play the key role in solving it. By offering smarter, more responsive systems, ongoing optimization, and automation with context, vendors help customers focus on what matters the most. 

This isn't just about efficiency — it's about creating a partnership between vendors and customers. Together, they must be able to cut through the noise and be able to provide clarity in the fight against modern cyber threats. Vendors must ensure their solutions don't just alert but empower users to make the best decisions. 

Don't miss the upcoming free Dark Reading Virtual Event, "Know Your Enemy: Understanding Cybercriminals and Nation-State Threat Actors," Nov. 14 at 11 a.m. ET. Don't miss sessions on understanding MITRE ATT&CK, using proactive security as a weapon, and a masterclass in incident response; and a host of top speakers like Larry Larsen from the Navy Credit Federal Union, former Kaspersky Lab analyst Costin Raiu, Ben Read of Mandiant Intelligence, Rob Lee from SANS, and Elvia Finalle from Omdia. Register now!

**About the Author**

Security Engineer

Supradeep Bokkasam is a Brisbane-based information security engineer with nearly 20 years of IT experience. He has worked extensively in the content delivery network (CDN) space, focusing on network and application security, identity and access management (IAM), and zero-trust network access (ZTNA). He has worked with organizations across various sectors to identify and safeguard critical assets against cyber threats.

The Vendor's Role in Combating Alert Fatigue

Cloud service providers are getting better at protecting data, pushing adversaries to develop new cloud ransomware scripts to target PHP applications, a new report says.

Instead of solely leaning on leaky buckets and cloud service provider (CSP) vulnerabilities to exfiltrate sensitive data, a fresh crop of cloud-targeting ransomware is aimed instead at exploiting unprotected Web applications to drop encryptors and lock up victims' data.

The pivot to focusing on PHP applications demonstrates the success that CSPs have had in shoring up their environments with policies like AWS's Key Management Service, according to a new report from SentinelOne on the state of cloud ransomware landscape in 2024. CSPs can now ensure that almost no data is really lost, thanks to policies that require a waiting period and confirmation before data can be deleted. There are some fairly exotic malicious workarounds for some of these protections, but attacks can easily be blocked by implementing service control policies, the report said.

**Cloud Ransomware's New Look at Web Applications**

Cloud ransomware operators have started to mine Web applications for opportunities in increasing volumes, according to SentinelOne.

"Web applications are often run via cloud services," SentinelOne's report explained. "Their more minimal nature makes cloud environments a natural hosting point where the applications are easier to manage and require less configuration and upkeep than running on a full operating system. However, Web applications themselves are vulnerable to extortion attacks."

Related:5 Ways to Save Your Organization From Cloud Security Threats

Analysis uncovered new ransomware scripts specifically developed to attack PHP applications — such as a Python script named "Pandora," and another attributed to Indonesian-based threat actor IndoSec group.

"The Pandora script uses AES encryption to target several types of systems, including PHP servers, Android, and Linux," the report added. "The PHP ransom functions encrypt files using AES via the OpenSSL library. The Pandora Python script runs on the Web server, writing the PHP code output to the path pandora/Ransomware with a file name provided as an argument at runtime and appended with the php extension."

The ransom script targeting PHP applications developed by IndoSec uses a PHP backdoor to manage and delete files, according to the report. It searches through directories, reads, and then encodes the file contents using a Web service's API.

"This is an interesting approach because the encryption is provided through a remote service, rather than using native functionality like many other tools," the report noted.

**Using Legitimate Cloud-Native Functions to Steal Data**

Aside from trying to breach them, adversaries have also figured out how to use these cloud services themselves to exfiltrate stolen data, the report explained. SentinelOne offers the example of September Rhysdia and BianLian cloud ransomware attacks that abandoned their historical exfiltration tools like MEGAsync and rclone, and instead used Azure Storage Explorer to download the data. The following month, the LockBit ransomware group was discovered using Amazon's S3 storage to exfiltrate data from Windows and macOS systems, SentinelOne added.

Related:Google AI Platform Bugs Leak Proprietary Enterprise LLMs

In keeping with the trend, the SentinelOne research identified a new Python script on VirusTotal it named "RansomES." This code is designed to infiltrate a Windows system, look for files with extensions that indicate the file contains data, including .doc, .xls, .jpg, .png, or .txt. Once those files have been identified, the RansomES code allows the ransomware attacker to exfiltrate those files to an S3 storage bucket or an FTP site, and encrypt the local versions.

"RansomES is a simple script, and we do not believe it has been used in the wild," the report noted. "The author included an Internet connectivity check to the WannaCry killswitch domain, which may suggest the script was developed by a researcher or someone with an interest in threat intelligence."

Related:2 Zero-Day Bugs in Microsoft's Nov. Update Under Active Exploit

The key to protecting data against Web application cloud ransomware attacks is to assess the overall cloud environment to protect against misconfigurations and overly permissive storage buckets, the report concluded.

"Additionally, always enforce good identity management practices such as requiring MFA on all admin accounts, and deploy runtime protection against all cloud workloads and resources," according to SentinelOne.

Cloud Ransomware Flexes Fresh Scripts Against Web Apps

The CISA and FBI have issued an advisory detailing a sophisticated cyberespionage campaign by state-sponsored Chinese hackers that…

The CISA and FBI have issued an advisory detailing a sophisticated cyberespionage campaign by state-sponsored Chinese hackers that has successfully infiltrated US telecommunications networks.

The US government has exposed a large-scale cyberespionage campaign launched by Chinese state-sponsored hackers. This campaign is mainly targeting critical telecommunications infrastructure in the United States and has resulted in the theft of sensitive data, including call records and private communications of individuals involved in government and political activities.

It is worth noting that this security advisory follows just a month after China’s Salt Typhoon group was accused of hacking AT&T and Verizon, allegedly accessing sensitive wiretap data.

According to the advisory issued by the Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI), Chinese state-sponsored actors have successfully compromised the networks of multiple telecommunications providers.

> _“Specifically, we have identified that PRC-affiliated actors have compromised networks at multiple telecommunications companies to enable the theft of customer call records data, the compromise of private communications of a limited number of individuals who are primarily involved in government or political activity, and the copying of certain information that was subject to U.S. law enforcement requests pursuant to court orders.”_
> 
> CISA – FBI

One of the most concerning aspects is the possible impact of this attack on US national security. By targeting telecommunications providers, hackers can gain a trove of sensitive information, including communications between government officials, military personnel, and other high-value targets. The compromised data could be used for intelligence gathering, blackmail, or other malicious purposes.  

The advisory states that the US government has taken steps to mitigate the threat posed by this cyberespionage campaign. CISA and the FBI are working closely with affected telecommunications providers to identify and address vulnerabilities. Additionally, the US government is urging individuals and organizations to take steps to protect themselves from cyber threats. 

****The China Threat****

While the United States is known for targeting Chinese infrastructure, China has also emerged as a persistent threat to US critical infrastructure, with state-sponsored hacking groups repeatedly targeting key sectors.

Last month, Chinese hacking group Salt Typhoon (aka GhostEmperor, FamousSparrow, and Earth Estries) breached the systems of major US telecom companies AT&T, Verizon, and Lumen Technologies, potentially compromising wiretap systems used in criminal investigations. 

Another Chinese state-sponsored threat actor Volt Typhoon hacked Singapore-based Singtel a few days back, probably in preparation for attacks against US wireless carriers, Bloomberg reported. 

Considering the extensive implications of such persistent threats, telecommunications providers must invest in advanced security technologies and train their employees to recognize/respond to cyber threats. Additionally, international cooperation is essential to combat cybercrime and hold cybercriminals accountable.

1.  **United Airlines Hacked by Chinese Group Behind The OPM Breach**
2.  **Chinese SMS Phishing Group Hits iPhone Users in India Post Scam**
3.  **China Hacked Federal Deposit Insurance Corporation with Malware**
4.  **Five Eyes Accuses Chinese APT40 for Hacking Government Networks**
5.  **Critical Vulnerabilities Expose Nearly 1 Million DrayTek Routers Globally**

CISA and FBI: Chinese Hackers Compromised US Telecom Networks

If the government truly wants to protect the US's most vital assets, it must rethink its cybersecurity policies and prioritize proactive, coordinated, and enforceable measures.

Jeffrey Wells, Visiting Fellow, National Security Institute at George Mason University's Antonin Scalia Law School

November 14, 2024

6 Min Read

Source: Sergey Borisov via Alamy Stock Photo

COMMENTARY

The recent revelations about the Salt Typhoon cyber-espionage group breaching major US telecommunications companies, including Verizon, AT&T, and Lumen Technologies, lay bare a systemic vulnerability in America's approach to cybersecurity. This incident is not just an isolated attack; it's an indictment of the US government's inadequate response to the increasing cyber threats posed by state-backed entities like China. Despite years of warnings and multiple high-profile breaches, the government's cybersecurity posture remains reactionary, fragmented, and underwhelming.  

**The Critical Failures in US Cybersecurity Strategy**

Salt Typhoon's targeting of systems used for government intelligence collection, including those integral to surveillance and wiretapping capabilities, is a brazen assault on America's most sensitive digital infrastructure. It exposes a critical flaw: the lack of robust, proactive measures to secure such vital systems. How did a foreign state-backed group infiltrate and potentially remain undetected in these systems for months? The answer lies in insufficient federal oversight, underinvestment in cutting-edge defenses, and an overreliance on private companies to self-police. 

US telecom giants have historically enjoyed light regulatory oversight, often lobbying for fewer obligations and responsibilities. The government, in turn, has adopted a laissez-faire approach, trusting these corporations to manage their cybersecurity. This model is fundamentally flawed. When private entities prioritize profits over robust security measures, it opens the door for adversaries like Salt Typhoon to exploit weak points. The compromised systems at Verizon, AT&T, and Lumen Technologies illustrate the risks of letting corporations with such immense national security implications operate without stringent and enforceable cybersecurity standards. 

**Lawmakers' Outrage: Too Little, Too Late**

In the wake of the Salt Typhoon breach, US lawmakers have begun demanding answers from the affected companies, calling for greater accountability and urging federal regulators to impose stricter standards. While this post-breach outrage may seem like a strong response, it's another chapter in the reactive cycle that defines American cybersecurity policy. Rather than addressing systemic vulnerabilities before they are exploited, federal agencies and lawmakers are again playing catch-up. 

The reality is that sophisticated state-backed actors like Salt Typhoon have likely been probing and compromising critical US infrastructure for years, undetected and unchallenged. The question is not just why this breach happened but why the US government consistently finds itself responding after the fact. The issue goes beyond the individual companies breached — this pattern reflects a more significant failure in Washington to develop a proactive, cohesive, well-resourced cybersecurity strategy.

**The Illusion of Federal Oversight**

Federal authorities, including the FBI and the Cybersecurity and Infrastructure Security Agency (CISA), are reportedly investigating the extent of these breaches. However, these investigations often lack the teeth and reach necessary to effect real change. Despite the resources and expertise within agencies like CISA, they are limited in their power to enforce compliance or impose significant penalties on corporations that fail to meet cybersecurity benchmarks. This hands-off approach only emboldens adversaries who know that American companies are not adequately protected and that the government's response mechanisms are limited. 

Further, the fragmented nature of federal oversight complicates a comprehensive defense strategy. With multiple agencies sharing responsibility — yet lacking a unified and coordinated approach — gaps in response capabilities are inevitable. The breaches at Verizon, AT&T, and Lumen Technologies should serve as a wake-up call: The current oversight model is failing to keep pace with the sophistication of state-backed cyber threats. 

**The Need for a Paradigm Shift**

The US must abandon its outdated and ineffective approach to cybersecurity regulation to address these vulnerabilities. Here are key steps the government should take: 

*   Mandatory federal standards and penalties: Telecom companies are critical to national security. They must be held to federal standards that are not just recommendations but legal obligations, with meaningful penalties for non-compliance. The government cannot leave the protection of such vital infrastructure to the discretion of profit-driven entities. 
    
*   A unified cyber defense agency: The United States must streamline its response by creating a centralized agency with the power and authority to coordinate and enforce cybersecurity measures across the public and private sectors. The current patchwork of agencies is insufficient in an era where cyber threats know no borders or jurisdictions. 
    
*   Investment in advanced detection and response capabilities: The government must invest heavily in advanced technologies that provide real-time monitoring and automated response capabilities. Relying on companies to detect and report breaches months after they occur is unacceptable when adversaries can inflict catastrophic damage in seconds. 
    
*   Active cyber deterrence: The US must adopt a more aggressive cyber-deterrence strategy. The current approach of merely investigating breaches after the fact does not dissuade adversaries. It's time for the government to develop and deploy offensive cyber capabilities that signal a clear and present cost for any attempt to infiltrate US systems. 
    

**The Cost of Complacency**

The Salt Typhoon breach is just the latest chapter in a series of cyber-espionage incidents that have exposed the inadequacies of the US cybersecurity framework. If this pattern of complacency and reactionary policy continues, it won't be long before another attack not only compromises intelligence-gathering capabilities but potentially cripples critical infrastructure. The stakes are too high for lawmakers and federal agencies to continue operating with the exact amount of inertia and neglect. 

If Washington truly wants to protect the nation's most vital assets, it must rethink its cybersecurity policies and prioritize proactive, coordinated, and enforceable measures. Otherwise, the US will continue to react to — rather than prevent — attacks that undermine its national security and global standing. 

Don't miss the free Dark Reading Virtual Event, "Know Your Enemy: Understanding Cybercriminals and Nation-State Threat Actors," Nov. 14 at 11 a.m. ET. Don't miss sessions on understanding MITRE ATT&CK, using proactive security as a weapon, and a masterclass in incident response; and a host of top speakers like Larry Larsen from the Navy Credit Federal Union, former Kaspersky Lab analyst Costin Raiu, Ben Read of Mandiant Intelligence, Rob Lee from SANS, and Elvia Finalle from Omdia. Register now!

**About the Author**

Visiting Fellow, National Security Institute at George Mason University's Antonin Scalia Law School

Jeffrey Wells is a distinguished cybersecurity, technology, and geopolitical risk leader with over 35 years of experience. His expertise is crucial in addressing cyber threats with significant geopolitical and security implications. Wells is a Visiting Fellow at George Mason University's Cyber and Tech Center (CTC) and a Truman National Security Project Defense Council Fellow.

He has extensive experience helping organizations design and operationalize cyber resiliency strategies, programs, incident response, and instituting business continuity worldwide.

As a founding partner of the NIST's National Cybersecurity Center of Excellence and a Visiting Fellow at the National Security Institute, Jeffrey is proficient in deploying and operationalizing cybersecurity standards and best practices in the full spectrum of IT/OT and infrastructure ecosystems.

Tag

#intel