The "SANS 2024 State of ICS/OT Cybersecurity" report suggests organizations are going to shift spending from security technologies protecting industrial control systems and operational technology environments to nontechnical activities, such as training and incident response.

Source: SANS State of ICS/OT Cybersecurity 2024, Figure 18

In the "SANS 2024 State of ICS/OT Cybersecurity" report, 530 professionals working in critical infrastructure sectors were asked which technologies they have in their operational technology (OT) environments and which ones they were planning to add in the next year-and-a-half. The two lists highlight which technologies are widely deployed and what areas security teams are going to focus on next. 

The top technologies currently in use are access controls (81%); backup and recovery tools (74.4%); endpoint detection and response (EDR) tools, such as traditional antivirus (73%); segmentation between control systems and higher risk networks (66%); and secure remote access with multifactor authentication (65%). These categories have seen "massive jumps in implementation," SANS said in the report. Just 53% of respondents reported using EDR in 2019, which comes out to a 20% increase in 2024.

"We often describe ICS/OT as the 'M&M' model: hard shell, gooey center. This is why we focus a lot on IT–OT boundaries (i.e., the hard shell)," the report said. "However, security professionals need to also focus on toughening up that gooey center."

Securing that "gooey center" may be one of the reasons for a shift suggesting more nontechnology spending, such as for training, simulations, and incident response. Indeed, the five most-planned activities for the next 18 months are implementing industrial control system (ICS) specific cybersecurity metrics or dashboards (37%), deploying ICS network security monitoring and anomaly detection (33%), rolling out control system enhancements and upgrades (32%), conducting ICS-specific cybersecurity training (31%), and running ICS-specific incident response tabletops or simulations (30%). 

With the exception of cybersecurity metrics and dashboards, these planned technologies are already in use by nearly half of the respondents. The fact that another 30%-plus are making plans to use them suggests that the industry is on the brink of another jump in implementation in these areas.

It's worth noting that the three least deployed technologies for ICS defense had a "surprisingly" larger number of respondents planning to invest in them over the next year-and-a-half. Roughly a quarter of respondents have deployed the following technologies and solutions at this time: software bill of materials, or SBOM(25%), industrial cloud security (26%), and security orchestration, automation, and response, or SOAR (28%). A higher-than-average number of respondents have plans to start using SBOM (28%), industrial control security (23%), and SOAR (30%). 

The planned rates indicate these technologies may become more common across ICS security programs soon, SANS said.

**About the Author**

Jennifer Lawinski is a writer and editor with more than 20 years experience in media, covering a wide range of topics including business, news, culture, science, technology and cybersecurity. After earning a Master's degree in Journalism from Boston University, she started her career as a beat reporter for The Daily News of Newburyport. She has since written for a variety of publications including CNN, Fox News, Tech Target, CRN, CIO Insight, MSN News and Live Science. She lives in Brooklyn with her partner and two cats.

Incident Response, Anomaly Detection Rank High on Planned ICS Security Spending

Though its third-quarter earnings report confirms that the company remains on track, it's unclear how that will be affected if the threat actors commit further damage.

Source: Todd Strand via Alamy Stock Photo

Halliburton Company, a multinational corporation known for its oil and gas products and services, reported that its losses after a ransomware attack in August have added up to $35 million.

In a filing with the US Securities and Exchange Commission (SEC), Halliburton reported that it became aware of unauthorized third-party access to its systems on Aug. 21, prompting it to launch an investigation alongside its cybersecurity response plan.

In order to contain the breach, Halliburton was forced to shut down some of its systems. In an 8-K filing, the company confirmed that the threat actors were able to exfiltrate data in the attack. It also revealed that the RansomHub ransomware gang was behind the attack and stolen data.

It remains unclear the scope of the breach and what kind of information was stolen, as the investigation in ongoing. However, Halliburton reported that it was unlikely that the breach would have a material impact on its finances, with its 2024 third-quarter earnings report confirming that estimate.

"We experienced a $0.02 per share impact to our adjusted earnings from lost or delayed revenue due to the August cybersecurity event and storms in the Gulf of Mexico," stated Jeff Miller, chairman, president, and CEO at Halliburton.

The cost of mitigating the cyberattack was a small price to pay considering Halliburton's size as a company. But the threat actors may still yet decide to sell the data, exposing Halliburton even further and requiring additional damage control.

**About the Author**

Halliburton Remains Optimistic Amid $35M Data Breach Losses

Windows users are at risk for full device takeover by an emerging malicious version of the Remcos remote admin tool, which is being used in an ongoing campaign exploiting a known remote code execution (RCE) vulnerability in Microsoft Office and WordPad.

Source: imageBROKER.com GmbH & Co. KG via Alamy Stock Photo

Threat actors have given the commercially available Remcos remote access tool a new malicious makeover, wrapping its malware code in several layers of varying script languages, including JavaScript, VBScript, and PowerShell, to avoid detection and analysis and achieve full takeover of Microsoft Windows devices.

New findings from Fortinet researcher Xiaopeng Zhang warn Microsoft Windows users about a new campaign using this new-and-improved version of Remcos RAT that exploits a known remote code execution (RCE) vulnerability arising from how unpatched Microsoft Office and WordPad instances parse files.

The attack chain starts with a phishing email intended to lure users into clicking an Excel file disguised as a business order, according to the report. Once the file is activated it exploits the bug (CVE-2017-0199) and downloads the malware payload.

**Remco's New Version Is Good at Avoiding Analysis**

"Its code is wrapped in multiple layers using different script languages and encoding methods, including JavaScript, VBScript, Base64-encoded, URL-encoded, and PowerShell, to protect itself from detection and analysis," according to the researcher. "Once the downloaded exe file, dllhost.exe, starts, it extracts a batch of files into the %AppData% folder. Some of the key data are hidden in these files."

From there, the host runs a piece of heavily obfuscated PowerShell code that, importantly, works only on the 32-bit PowerShell process, the report added.

Next, the malware runs self-decryption code hidden beneath a rat's nest (pun intended) of unnecessary code to avoid analysis. But that isn't the only sophisticated evasion technique utilized by the latest version of malicious Remcos RAT. According to the report, the campaign throws up several analysis road blocks throughout the attack chain, including installing a vectored exception handler, and gaining and calling system APIs in an inconsistent, hard to track way. It also uses a tool called "ZwSetInformationThread()" to check for a debugger, the report added.

"The malicious code calls API ZwSetInformationThread() with the argument ThreadHideFromDebugger (0x11) and the current thread (0xFFFFFFFE). This mechanism in Windows can conceal a thread’s existence from debuggers," explained Zhang. "If a debugger is attached to the current process, it exits immediately once the API is called."

The malware further uses an API hooking technique to avoid detection.

"The malicious code simulates executing multiple API instructions (say, two instructions) at the beginning and then jumps to the API to execute the rest of the instructions (beginning with the 3rd instruction)," according to the report. "Whenever any ... detection conditions are triggered, the current process (PowerShell.exe) can become unresponsive, crash, or exit unexpectedly."

Once ready, the threat actors download an encrypted file with the malicious version of Remcos RAT that is run in current process's memory, effectively making this latest variant fileless, the report pointed out.

**Defend With Patching, Training, and Endpoint Protection**

"Remcos collects some basic information from the victim's device," Zhang added. "It then encrypts and sends the collected data to its C2 server to register that the victim's device is online and ready to be controlled."

Anti-analysis and tricky obfuscation techniques aside, Darren Guccione, CEO and founder of Keeper Security, noted in an emailed statement that low-tech phishing and social engineering that remain among the very most dangerous enterprise cybersecurity threats.

"Preventing these attacks requires a combination of technical defenses and employee awareness," he wrote. "Recognizing red flags, such as unusual senders, urgent requests and suspicious attachments, can help reduce human error. Regular training and robust security measures empower employees to act as the first line of defense."

Robust endpoint security should also be a priority to defend against these types of attacks, as well as a basic patch management strategy, according to a statement from Stephen Kowski, field CTO for SlashNext Email Security+.

"Protection requires a multi-faceted approach: keeping Microsoft Office fully patched, implementing advanced email security to detect and block malicious attachments in real time, and deploying modern endpoint security to identify suspicious PowerShell behaviors," Kowski commented. "Most critically, since this attack relies on social engineering through phishing emails, organizations should ensure their employees receive regular security awareness training focused on identifying suspicious attachments and purchasing order-themed lures."

Revamped Remcos RAT Deployed Against Microsoft Windows Users

It's polite to listen to advice that people are willing to share, but not all of it will be useful for you. Here's how to separate the wheat from the chaff.

Source: Westend61 GmbH via Alamy Stock Photo

COMMENTARY  
As a teenager, I commented to my father that not everyone gives good advice. In fact, some people give just plain bad advice. My father told me that while I didn't have to take everyone's advice, I needed to listen to what everyone was saying to me.

Knowing whose advice to take versus whose advice to leave is a skill that most people spend a lifetime honing. One thing is for sure, though: There is no shortage of advice, information, and distraction. This is particularly true in our profession — it seems that most everyone has something to say about just about every topic in cybersecurity.

Thus, as most of us mature and grow as security professionals (and as people), we realize that knowing what to ignore is just as important as knowing what to pay attention to. If we pursued every new idea that came our way, we would spend our entire day churning away on a variety of different possibilities, most of which would bring little improvement to our organization's security posture. On the other hand, if we ignored everything new, we would miss plenty of great opportunities to improve the ways in which we defend our organizations.

**How to Organize Your Thinking About Advice**

Clearly, we need to find a happy balance. The question is, how can we know what we should ignore versus what we should act on? There is no absolute answer, but here are a few guidelines to help assess advice. To illustrate an example, we will talk about improving the state of your organization's API security.

*   So what?: When evaluating whether to pursue a suggestion, it can be helpful to ask the question: "So what?" If I were to pursue this, what impact would it have? Is there a real potential for any outcome that would be worth it, or will this merely be a time sink? If the impact is nonexistent, that is probably a sign that we can safely ignore it. In our scenario, improving API security is almost certain to yield value, so the suggestion would remain on the table.
    
*   What's my action?: It can also be helpful to think about what, if any, action is required from you. Is any action required? Will this bring tangible results? Or is this just a whirlwind of information that will not yield any material change in your day-to-day? If there is no action, you can probably look elsewhere for suggestions. Improving the state of API security would definitely involve action from me, so I'm still listening.
    
*   Practicality: Unless we are in a theoretical research position (which most of us are not), any idea we consider needs to have a practical application. It can be helpful to ask the question: "Is this an academic exercise?" If it is, it is probably safe to move along. There are many API security improvements a colleague might recommend to me that would have real-world impact, so I'm still taking notes.
    
*   Strategic fit: Most security teams have a strategic direction that includes priorities designed to steer them in that direction. If some new API solution grabs people's attention, for example, it is worth my taking a moment to slow down and assess whether it fits the team's strategy. If not, it is probably best to move along.
    
*   Detraction: When assessing a suggestion, most people will think about what it could potentially bring to the security team. What fewer people consider, unfortunately, is what the suggestion could detract from. This is an important point to consider, however. If pursuing a suggestion will take away from other, more important activities, it is likely not a good one. If this theoretical API security project took resources away from threat detection and response, we'd want to know that and weigh the pros and cons.
    
*   Source: When an idea is suggested, it can be helpful to consider the source. Some people suggest practical, actionable ideas that fit the organization's strategic direction and don't detract from other important activities. Other people suggest ideas that are more half-baked. It is worth asking: "Has this person led us astray in the past?" If they have, it is likely safe to ignore their ideas, absent any compelling evidence that the ideas are good ones. If, for example, my colleague tends to make suggestions based on their friends' social media posts, I am less inclined to get excited about any new API security ideas they bring up.
    

As security professionals, we all get a tremendous amount of advice, information, and distractions coming at us every day. Pursuing all of it would be unwise — as would be pursuing none of it. We can reach a happy medium by following some guidelines. Regardless of what methods we use to help us sort and filter what comes at us, doing so successfully is certainly an important part of remaining productive in our careers.

**About the Author**

Field CISO, F5

Josh Goldfarb is currently Field CISO at F5. Previously, Josh served as VP and CTO of Emerging Technologies at FireEye and as Chief Security Officer for nPulse Technologies until its acquisition by FireEye. Prior to joining nPulse, Josh worked as an independent consultant, applying his analytical methodology to help enterprises build and enhance their network traffic analysis, security operations, and incident response capabilities to improve their information security postures. Earlier in his career, Josh served as the Chief of Analysis for the United States Computer Emergency Readiness Team, where he built from the ground up and subsequently ran the network, endpoint, and malware analysis/forensics capabilities for US-CERT. In addition to Josh's blogging and public speaking appearances, he is also a regular contributor to Dark Reading and SecurityWeek.

What Listening to My Father Taught Me About Cybersecurity

Attackers abuse concatenation, a method that involves appending multiple zip archives into a single file, to deliver a variant of the SmokeLoader Trojan hidden in malicious attachments delivered via phishing

Source: Rawpixel.com via Shutterstock

Threat actors are exploiting the various ways that zip files combine multiple archives into one file as an anti-detection tactic in phishing attacks that deliver various Trojan malware strains, including SmokeLoader.

Attackers are abusing the structural flexibility of zip files through a technique known as concatenation, a method that involves appending multiple zip archives into a single file, new research from Perception Point has found. In this method, the combined file appears as one archive that actually contains multiple central directories, each pointing to different sets of file entries.

However, "this discrepancy in handling concatenated zips allows attackers to evade detection tools by hiding malicious payloads in parts of the archive that some zip readers cannot or do not access," Arthur Vaiselbuh, Windows internals engineer, and Peleg Cabra, product marketing manager from Perception Point, wrote in a recent blog post.

Abusing concatenation allows attackers to hide malware in zip files that even readers aimed at parsing the files for in-depth analysis, including 7.zip or OS-native tools, may not detect, according to Perception Point.

"Threat actors know these tools will often miss or overlook the malicious content hidden within concatenated archives, allowing them to deliver their payload undetected and target users who use a specific program to work with archives," Vaiselbuh and Cabra noted in the post.

**How to Exploit Zip Files**

To illustrate how zip files can be misused, the post breaks down the different ways that three popular zip archive readers — 7.zip, Windows File Explorer, and WinRAR — handle concatenated zip files.

7.zip, for example, will only display the contents of the first archive and then may display a warning that "there are some data after the end of the archive." However, this message often is overlooked and thus malicious files may not be detected, the researchers noted.

Windows File Explorer demonstrates different potential for malicious use as it "may fail to open the file altogether or, if renamed to .rar, will display only the 'malicious' second archive’s contents," according to the post. "In both cases, its handling of such files leaves gaps if used in a security context," Vaiselbuh and Cabra wrote.

WinRAR takes a different tack in that it actually reads the second central directory and displays the contents of the second and potentially malicious archive, making it "a unique tool in revealing the hidden payload," they added.

Ultimately, though sometimes these readers detect the malicious activity, the different ways that each reader handle concatenated files leaves room for exploit, leading to varying outcomes and potential security implications, according to Perception Point.

**Phishing Attack Vector**

The phishing attack that exploits concatenation observed by Perception Point starts with an email that purports to come from a shipping company and uses urgency to bait users. The email is marked with "High Importance" and includes an attachment, SHIPPING\_INV\_PL\_BL\_pdf.rar, sent under the guise that it's a shipping document that must be reviewed before a shipment can be completed.

The attached file appears to be a rar archive due to its .rar extension, but is actually a concatenated zip file, deliberately disguised to confuse the user not only by exploiting trust associated with rar files, but also bypassing basic detections that might rely on file extensions for initial file assessments, according to the post.

The file contains a variant of the known Trojan malware family SmokeLoader that's designed to automate malicious tasks such as downloading and executing additional payloads, which could include other types of malware, such as banking Trojans or ransomware.

However, when tested, only two of the three tools that parse zip files actually detected that there is a potentially malicious archive in the file, according to the post. Opening the attachment using 7.zip reveals only a benign-looking PDF titled "x.pdf," which appears to be an innocent shipping document. On the other hand, both Windows File Explorer or WinRAR fully expose the hidden danger.

"Both tools display the contents of the second archive, including the malicious executable SHIPPING\_INV\_PL\_BL\_pdf.exe, which is designed to run and execute the malware," Vaiselbuh and Cabra wrote.

**Mitigation of a Persistent Issue**

Perception Point security researchers contacted the developers of 7.zip to address the behavior they observed between its reader and of concatenated zip files, according to the post. However, their response did not acknowledge that it is any kind of vulnerability.

"The developer confirmed that it is not a bug and is considered intentional functionality — meaning this behavior is unlikely to change, leaving the door open for attackers to continue exploiting it," Vaiselbuh and Cabra wrote.

Given that the risk continues to exist for the observed attack vector to abuse these files in phishing attacks, users are urged to approach any email sent from an unknown entity that requires them to take immediate action by opening an unsolicited file with caution.

Enterprises also are encouraged to use advanced security tools that detect when a zip archive (or a malformed rar archive) is concatenated and recursively extract every layer. This type of analysis can ensure "that no hidden threats are missed, regardless of how deeply they are buried — deeply nested or concealed payloads are revealed for further analysis," Vaiselbuh and Cabra wrote.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Flexible Structure of Zip Archives Exploited to Hide Malware Undetected

Meta has maintained that Facebook did not mislead investors by not including mention of the Cambridge Analytica scandal in its forward-looking risk disclosures, but the plaintiffs say it was a glaring omission.

Souce: AlexanddraPopova via Shutterstock

The US Supreme Court will soon decide whether to allow a longstanding shareholder lawsuit against Meta's Facebook to proceed or to dismiss it as lawyers for the social media giant have asked.

The lawsuit involves a 2015 incident in which UK-based consultancy Cambridge Analytica obtained Facebook user data from a third-party firm and used it to create granular profiles for targeting users during political campaigns, on behalf of the Trump campaign. News of the data misuse surfaced in 2018 and provoked considerable concern in the US and elsewhere over privacy violations, data protection, and the role of social media in influencing politics.

**The Cambridge Analytica Fiasco**

Facebook faced intense scrutiny from US government and regulatory bodies over the incident. In July 2019, the US Federal Trade Commission (FTC) hit the company with a massive $5 billion fine in addition to new requirements for greater transparency and accountability for the company's data security and privacy practices.

Separately, a class of Facebook shareholders represented by Amalgamated Bank sued the company for, among other things, not disclosing the breach to shareholders and the public in a timely manner, thereby leading to a loss in shareholder value. The crux of their argument was that Facebook's legally obligated, forward-looking statements about risks to its business made no mention of the Cambridge Analytica breach or its impact on Facebook users. They argued that the company misled investors and others in phrasing the risks to data as hypothetical when, in fact, a breach had already happened.

The US Court of Appeals for the Ninth Circuit — the last to hear the case — allowed the Amalgamated lawsuit to proceed, overturning a District Court ruling on the matter.

**Ignoring Cambridge Analytica Scandal Not Misleading?**

In the US Supreme Court hearing on the case this week, Facebook legal counsel Kannon Shanmugam said the Ninth Circuit had got it wrong in holding that a risk disclosure can be misleading simply because it did not disclose that the stated risk had already materialized in the past.

"A risk disclosure warrants that a type of event may cause harm in the future. It usually makes no representation that the event had never previously occurred," he said in the hearing.

"Just as a statement that 'the road may be flooded if it rains' cannot be misleading simply because it rained yesterday, a typical risk disclosure cannot be misleading simply because the triggering event had occurred in the past," he argued.

Kevin Russell, representing the plaintiffs for Amalgamated Bank in the case, used similar analogies to argue for the case to proceed. "Facebook admits that if a student tells his parents that there no a risk he may fail an exam when he's already done so, that is misleading," Russell noted. "\[The statement\] implies it's impossible that he won't, when that isn't true. The same is true of many risk factor statements, including the ones at issue in this case."

In his argument, Russell conceded that companies should not be obligated to disclose every past material risk incident in their forward-looking risk disclosures. However, there is an obligation for organizations not to mislead people into thinking that a major omitted risk event had not happened, he said.

When asked how Facebook should have phrased its risk disclosure instead, Russell noted the company should have included a mention of Cambridge Analytica incident. "I think that they could have said what they said and then said something like: Such improper disclosure or misuse of user data has occurred in the past, including recently on a substantial scale." Such a disclosure would eliminate any potential misimpression that the risks Facebook was referring to in its disclosure were purely hypothetical, Russell said.

**Supreme Court Justices: Data Risk Is All About Context**

In responding to Shanmugam's argument, Justice Elena Kagan said a lot depends on the context in which a forward-looking risk statement is made. She used a hypothetical example of a fire at a production plant that damages operations substantially, and a risk statement that merely notes fire as a potential risk to the business without actually mentioning such an accident had already happened.

"The typical investor would think it's kind of misleading for you to make this statement that's framed entirely in a hypothetical if, in fact, there's no more plant and no more production capacity," she noted.

Justice Samuel Alito used the same example to echo a similar sentiment. "A statement that simply blandly says that there's a possibility of a risk can, in context, be extremely misleading if there is a high probability of the risk materializing," he noted. Depending on the context, "the fact that something has happened in the past very often sheds light on the risk of a recurrence."

**About the Author**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

Facebook Asks Supreme Court to Dismiss Cambridge Analytica Lawsuit

Companies and organizations need to recognize the importance of investing in engineers who possess both the soft and hard skills required to secure open source software effectively.

Source: Yury Zap via Alamy Stock Photo

COMMENTARY

Open source security incidents aren't going away. The reliance on open source software (OSS) increases year-over-year, with more than 95% of all software, including open source, in some capacity. From operating systems to critical libraries to Web applications and more, open source software (OSS) plays a pivotal role in the current technology landscape. However, this widespread reliance introduces significant security risks. As the use of OSS continues to evolve, so does the importance of securing it. This responsibility falls not on individual hobbyist developers, but on the companies and organizations that have the resources to dedicate engineers specifically to open source security. These organizations are the ones that benefit the most from open source and should be the ones who contribute the most back.  

**Essential Skills for Open Source Security Developers**

Securing open source is similar to securing closed source, but many of the skills required are of higher importance for open source, due to various factors. Open source is public and tends to have broader adoption than much closed source software. A closed source tool with a security vulnerability used by a handful of customers is going to have a very different impact than something like OpenSSH having a vulnerability, given its use on millions of servers worldwide. 

I hope this doesn't come as a surprise, but the most important open source skills to have are soft skills. Most software development time is spent doing things other than actually writing code. Here are a few key skills:  

*   Public collaboration: Open source projects are inherently collaborative and involve contributors from around the globe. Effective communication ensures that security practices are understood and implemented correctly. 
    

*   Preventing miscommunication: Many security bugs arise from misunderstandings. Clear documentation and open dialogues can prevent these issues from occurring. 
    

*   Proactive approach: Keeping security at the forefront of daily tasks helps in early detection of potential vulnerabilities. 
    

*   Continuous vigilance: A security-first mindset encourages constant evaluation of code for potential risks. 
    

*   Responsibility: Treating open source projects with the same seriousness as closed source commercial projects ensures higher security standards. 
    

*   Accountability: Developers who feel a sense of ownership are more likely to produce secure and reliable code. 
    

Just because soft skills are more important than hard skills for software development doesn't mean those hard skills are irrelevant. They are still important, and a few of them in particular are of focused importance for open source security. The open source community gets the benefit of a project being public, enabling the community to come together to secure the project with experts in different areas providing their expertise. However, with open source being public, it also exposes projects to malicious actors, like we saw in the XZ compromise, where a bad actor maintainer contributed innocuous-looking, but ultimately malicious, code. This is why software engineers focused on open source security need to be vigilant and experienced to know what to look for when they get contributions from anonymous developers. Here are some of the skills that are important: 

1.  Security Engineering and Threat Modeling 
    

*   Understanding attack vectors: Knowledge of how vulnerabilities are exploited is crucial. 
    

*   Techniques like STRIDE: Familiarity with threat modeling methodologies helps in identifying and mitigating risks. 
    

*   Common vulnerabilities: Awareness of issues like SQL injection, cross-site scripting (XSS), and buffer overflows is essential. 
    

*   Language-specific vulnerabilities: Each programming language has its own set of security concerns. This is especially important for languages and ecosystems that don't have built-in memory safety mechanisms. 
    

*   Ecosystem proficiency: Knowledge of the packaging ecosystem like PyPI, npm, etc., and how software is developed in that ecosystem is important to understand external risks to the project like upstream dependencies. You can write perfectly safe code and include a vulnerable or malicious dependency and ship insecure software. Knowing when to include a dependency and when it's better to write the functionality yourself is very important as well. 
    

*   Build pipelines: Incorporating security checks into continuous integration and deployment processes ensures ongoing security. Open source developers wear multiple hats and need to understand and secure the continuous integration flow. The artificial intelligence (AI) analog would be the training pipeline. 
    

*   Contextual awareness: Understanding how software will be used by consumers helps in identifying potential security flaws. 
    

*   Automated testing: Implementing tools that automatically scan for vulnerabilities can catch issues early. 
    

*   Comprehensive test coverage: Ensuring that all parts of the code are tested reduces the risk of overlooked vulnerabilities. 
    

As the reliance on open source software continues to grow, so does the necessity for open source developers focused on security. This need is becoming even more critical with the rise of open source AI projects. Open source AI introduces new layers of complexity and opacity due to massive datasets and the probabilistic nature of trained models. The sheer volume of data and the intricacies of machine learning algorithms make it challenging to identify vulnerabilities and predict how models might behave in unforeseen circumstances. 

The "black box" aspect of AI models means that even the developers may not fully understand how inputs are being processed to produce outputs. This opacity can be exploited, leading to security breaches such as data poisoning, adversarial attacks, and unintended bias. Therefore, securing open source AI requires specialized skills and a deep understanding of both AI technologies and security principles. 

Companies and organizations must recognize the importance of investing in engineers who possess both the soft and hard skills required to secure open source software effectively, especially in the rapidly evolving field of AI. By fostering these skills, we can enhance the security of open source projects, benefiting individual organizations and the global community that relies on them. 

**About the Author**

Co-Founder & Chief Technology Officer, Kusari

Michael Lieberman is co-founder and chief technology officer (CTO) of Kusari, where he helps build transparency and security in the software supply chain. He has extensive engineering and architecture expertise with an emphasis on cloud-native technologies and security and privacy use cases. Prior to Kusari, he held engineering leadership positions with Citi, Mitsubishi UFJ Financial Group (MUFG), and Bridgewater Associates. Michael is an active member of the open source community, co-creating the GUAC and FRSCA projects and co-leading the CNCF’s Secure Software Factory Reference Architecture white paper. He is also co-chair of the Cloud Native Computing Foundation Financial Services User Group and an OpenSSF TAC and SLSA steering committee member.

Open Source Security Incidents Aren't Going Away

Large language models (LLMs) can help app security firms find and fix software vulnerabilities. Malicious actors are on to them too, but here's why defenders may retain the edge.

Source: vs148 via Shutterstock

Security researchers and attackers are turning to AI models to find vulnerabilities, a technology whose use will likely drive the annual count of software flaws higher, but could eventually result in fewer flaws in public releases, experts say.

On Nov. 1, Google said its Big Sleep large language model (LLM) agent discovered a buffer-underflow vulnerability in the popular database engine, SQLite. The experiment shows both the peril and the promise of AI-powered vulnerability discovery tools: The AI agent searched through the code for variations on a specific vulnerability, but identified the software flaw in time for Google to notify the SQLite project and work with them to fix the issue.

Using AI just for software-defect discovery could result in a surge in vulnerability disclosures, but introducing LLM agents into the development pipeline could reverse the trend and lead to fewer software flaws escaping into the wild, says Tim Willis, head of Google's Project Zero, the company's effort to identify zero-day vulnerabilities.

"While we are at an early stage, we believe that the techniques we develop through this research will become a useful and general part of the toolbox that software developers have at their disposal," he says.

Google is not alone in searching for better ways to find — and fix — vulnerabilities. In August, a group of researchers from Georgia Tech, Samsung Research, and other firms — collectively known as Team Atlanta — used an LLM bug-finding system to automatically find and patch a bug in SQLite. And just last month, cybersecurity firm GreyNoise Intelligence revealed it had used its Sift AI system to analyze honeypot logs leading to the discovery and patching of two zero-day vulnerabilities affecting Internet-connected cameras used in sensitive environments.

Overall, companies are gaining more ways to automate vulnerability discovery, and — if they are serious about security — will be able to drive down the number of vulnerabilities in their products by using the tools in development, says Corey Bodzin, chief product officer at GreyNoise Intelligence.

"The exciting thing is we do have technology that allows people who \[care about\] security to be more effective," he says. "Sadly ... there are not many companies where that is ... a primary driver, but even in companies where \[security is\] purely viewed as a cost" can benefit from using these tools.

**Only the First Steps**

Currently, Google's custom approach is still bespoke and requires work to adapt to specific vulnerability-finding tasks. The company's Big Sleep agent does not to look for completely new vulnerabilities, but uses details from a previously discovered vulnerability to look for similar issues. The project has looked at smaller programs with known vulnerabilities as test cases, but the SQLite experiment is the first time they found vulnerabilities in production code, the Google Project Zero and Google DeepMind researchers stated in Google's blog post describing the research.

While specialized fuzzers would likely have found the bug, tuning those tools to perform well is a very manual process, says Google's Willis.

"One promise of \[L\]LM agents is that they might generalize across applications without the need for specialized tuning," he says. "Additionally, we're hopeful that \[L\]LM agents will be able to uncover a different subset of vulnerabilities than those typically found through fuzzing."

The use of AI-based vulnerability discovery tools will be a race between attackers and defenders. Manual code review is a viable way of finding bugs for attackers, who only need a single exploitable vulnerability or short chain of vulnerabilities. But defenders need a scalable way of finding and fixing applications, Willis says. While bug-finding tools can be a force multiplier for both attackers and defenders, the ability to scale up to analyze code will likely be a greater benefit for defenders, Willis says.

"We expect that advances in automated vulnerability discovery, triage, and remediation will disproportionately benefit defenders," he says.

**Focus AI on Finding and Fixing Bugs**

Companies that focus on using AI to generate secure code and fix bugs when found will deliver higher quality code from developers, says Chris Wysopal, co-founder and chief security evangelist at Veracode, an application security firm. He argues that automating bug finding and bug fixing are two completely different problems. Finding vulnerabilities is a very large data problem, whIle fixing bugs usually deals with perhaps a dozen lines of code.

"Once you know the bug is there — if you found it through fuzzing, or through an LLM, or using human code review — and you know what kind of bug it is, fixing it is relatively easy," he says. "So, LLMs favor defenders, because having access to source code and fixing issues is easy. So I'm kind of bullish that we can eliminate whole classes of vulnerabilities, but it's not from finding more, it's from being able to fix more."

Companies that require developers to run automated security tools before code check-in will find themselves on a path to paying down their security debt — the collection of issues that they know about, but have not had time to fix, he says. Currently, about half (46%) of organizations have security debt in the form of persistent critical flaws in applications, according to Veracode's 2024 State of Software Security report.

"The idea that you're committing code that has a problem in it, and it's not fixed, will become the exception, not the rule, like it is today," Wysopal says. "Once you can start to automate this fixing — and we're always getting better at automating finding \[vulnerabilities\] — I think that's how things change."

Yet, the technology will still have to overcome companies' focus on efficiency and productivity over security, says Bob Rudis, vice president of data science and security research at GreyNoise Intelligence. He points to the fixing of the two security vulnerabilities that GreyNoise Intelligence found and responsibly disclosed. The company only fixed the issues in two product models, but not others — despite the fact that the other products likely had similar issues, he says.

Google and GreyNoise Intelligence proved that the technology will work, but whether companies integrate AI into the development pipelines to eliminate bugs is still an open question.

Rudis has doubts.

"I'm sure a handful of organizations are going to deploy it — it's going to make like seven C files a little bit safer across a bunch of organizations, and maybe we'll get like a tick more security for the ones that can actually deploy it properly," he says. "But ultimately, until we actually change the incentive structure around how software vendors build and deploy things, and how consumers actually purchase and deploy and configure things, we are not going to see any benefit."

**About the Author**

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

AI &amp; LLMs Show Promise in Squashing Software Bugs

Direct cyberattacks on vehicles are all but unheard of. In theory though, the opportunity is there to cause real damage — data extraction, full system compromise, even gaining access to safety-critical systems.

Source: Marin Tomas via Alamy Stock Photo

Six unpatched vulnerabilities in a Mazda in-vehicle infotainment (IVI) system could be exploited with a simple USB in a moments' time, and one of them has legitimate consequences to vehicle safety.

These days, cars are just computers on wheels, and IVIs are their user interface. The IVI in most Mazda vehicles of recent years — like the Mazda3 and CX-3, 5, and 9 — are built with the Mazda Connect Connectivity Master Unit (CMU), developed by the Michigan-based Visteon Corporation. The CMU is a core hardware component that enables various connectivity services: smartphone integration, a Wi-Fi hotspot, and various remote monitoring and control features.

Recent research through Trend Micro's Zero Day Initiative (ZDI) has surfaced half a dozen vulnerabilities in the Mazda IVI. A few of them enable full system compromise, and access to various sensitive data. One of particular note could enable an attacker to pivot to the vehicle's Controller Area Network (CAN) bus — the central nervous system connecting its various component parts.

None of the vulnerabilities have been assigned a value according to the Common Vulnerability Scoring System (CVSS) yet. All of them remain unpatched as of this writing. On the plus side: They all require that an attacker physically insert a malicious USB into the center console. Such a scenario — carried out by a carjacker, or possibly a valet or dealer — is essentially unheard of in the real world to date.

Dark Reading has reached out to Visteon for further comment on this story.

**6 Mazda IVI Security Bugs**

Three of the vulnerabilities — CVE-2024-8358, CVE-2024-8359, and CVE-2024-8360 — target functions used to locate and extract specific files during software updates. Because the provided file path is not sanitized, an attacker can step in with their own malicious injection, which gets executed at the root level of the system. With a specially crafted command, this one-step hack could facilitate a full system takeover.

Another way to skin this cat would be to take advantage of CVE-2024-8357, affecting the CMU's System on Chip (SoC) running Linux. The SoC's boot process has no authentication in place, so an attacker with the ability to execute code can take advantage to manipulate files, establish persistence through reboots, and establish control over the system even before it boots up.

The Mazda IVI; Source: Trend Micro's ZDI

CVE-2024-8355 might seem at first a bit different from the rest but, in reality, it's caused by the same underlying problem: lack of sanitization of input data.

To establish a connection with an Apple device, the CMU will request the device's serial number. Because it doesn't apply scrutiny to that value, a spoofed device can send specially crafted SQL code instead. The system's DeviceManager will run that code at the root level, enabling all kinds of malicious outcomes: database exposure, arbitrary file creation, etc.

Last, but certainly not least, is CVE-2024-8356, a missing verification during the CMU software update process. This one, however, affects the unit's other processor, the Verification IP Microcontroller Unit (VIP MCU). The VIP MCU is designed to be separate from the SoC for security purposes, because instead of running the operating system, it connects to the vehicle's CAN bus. The CAN bus, in turn, connects the rest of the vehicle: everything from climate control to the engine and airbags. With a tampered firmware image, ZDI demonstrated that one can jump the SoC to manipulate the VIP MCU, and from there reach the CAN bus.

**Serious, But Unlikely Consequences**

"In truth, it's hard to predict what an attacker could do once they have access to a CAN bus," says Dustin Childs, head of threat awareness at ZDI. "Since the CAN bus serves as the nervous system of the vehicle, a threat actor could potentially impact whatever electronic control units (ECUs) or components that interact with the CAN bus." Translation: Attackers can subvert just about any conceivable part of the vehicle.

"The worst case scenario would be an attacker impacting the driving characteristic of the car, rendering it unsafe to operate," he adds.

Still, the threat is immaterial. For all of the exploits demonstrated by researchers, actual criminals still consistently stick to those older tried-and-true methods of compromise: a stolen set of keys; an unfurled clothes hanger slipped artfully in between a window and a door frame; or a rock, a window, and a good baseball toss.

"At this point, there isn't a lot of real-world impact," Childs admits. "However, as cars become more connected, remote exploitation becomes more realistic. In the last Pwn2Own Automotive, the team from Synacktiv exploited the modem of the Tesla Model 3 over-the-air to reach and interact with the onboard systems of the vehicle. It's just a matter of time until a complete, remote vehicle takeover becomes a real possibility."

He adds, "That's why manufacturers should build in security to each component and not rely on the defenses of other modules. A vehicle should have a multilayered protective system that assumes every message may be from a compromised source. The more we get ahead of the problem now, the easier it will be to react to it in the future."

**About the Author**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

6 Infotainment Bugs Allow Mazdas to Be Hacked With USBs

It remains unclear how the attackers gained access to Newpark Resources' system, or what they plan to do with any stolen data the strike may have spewed out.

Source: Don Mammoser via Alamy Stock Photo

Newpark Resources, a Texas-based oil drilling fluids system and composite matting systems provider, announced in a filing with the Securities and Exchange Commission (SEC) that it is dealing with the fallout of a ransomware attack it faced earlier this week.

The company has not shared details as to how the attackers gained access to its network, nor who the threat actors are or why they may have targeted Newpark. But after the breach was discovered, Newpark engaged its security response plan as expected and limited access to certain parts of its systems.

"The incident has caused disruptions and limitation of access to certain of the company's information systems and business applications supporting aspects of the company's operations and corporate functions, including financial and operating reporting systems," Newpark said.

According to Matt Hull, global head for Strategic Threat Intelligence at cybersecurity consultancy NCC Group, any data stolen from the critical infrastructure company has not yet appeared on any leak sites.

And because the company reverted to downtime procedures in response to the attack, it was able to continue manufacturing, and its field operations were uninterrupted. It hopes the attack will not have an effect on its financial conditions, it said.

"Organizations are facing an increasingly pressing challenge: maintaining the security benefits of segmentation while enabling controlled connectivity," stated Chris Grove, director of cybersecurity strategy at Nozomi Networks, in an emailed statement to Dark Reading. "Industrial organizations will need to ensure their defenders can quickly isolate and contain threats, while preventing interruptions to critical operations. This is especially important for sectors where downtime has serious consequences in terms of public safety and economic impact, as would be the case with a critical infrastructure sector."

**About the Author**

Source

DARKReading