Google has announced that it's going to start blocking websites that use certificates from Entrust starting around November 1, 2024, in its Chrome browser, citing compliance failures and the certificate authority's inability to address security issues in a timely manner.
"Over the past several years, publicly disclosed incident reports highlighted a pattern of concerning behaviors by Entrust

Cybersecurity / Website Security

Google has announced that it's going to start blocking websites that use certificates from Entrust starting around November 1, 2024, in its Chrome browser, citing compliance failures and the certificate authority's inability to address security issues in a timely manner.

"Over the past several years, publicly disclosed incident reports highlighted a pattern of concerning behaviors by Entrust that fall short of the above expectations, and has eroded confidence in their competence, reliability, and integrity as a publicly-trusted \[certificate authority\] owner," Google's Chrome security team said.

To that end, the tech giant said it intends to no longer trust TLS server authentication certificates from Entrust starting with Chrome browser versions 127 and higher by default. However, it said that these settings can be overridden by Chrome users and enterprise customers should they wish to do so.

Google further noted that certificate authorities play a privileged and trusted role in ensuring encrypted connections between browsers and websites, and that Entrust's lack of progress when it comes to publicly disclosed incident reports and unrealized improvement commitments poses risks to the internet ecosystem.

The blocking action is expected to cover Windows, macOS, ChromeOS, Android, and Linux versions of the browser. The notable exception is Chrome for iOS and iPadOS, due to Apple's policies that don't permit the Chrome Root Store from being used.

As a result, users navigating to a website that serves a certificate issued by Entrust or AffirmTrust will be greeted by an interstitial message that warns them that their connection is not secure and isn't private.

Affected website operators are urged to move to a publicly-trusted certificate authority owner to minimize disruption by October 31, 2024. According to Entrust's website, its solutions are used by Microsoft, Mastercard, VISA, and VMware, among others.

"While website operators could delay the impact of blocking action by choosing to collect and install a new TLS certificate issued from Entrust before Chrome's blocking action begins on November 1, 2024, website operators will inevitably need to collect and install a new TLS certificate from one of the many other CAs included in the Chrome Root Store," Google said.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Google to Block Entrust Certificates in Chrome Starting November 2024

Plus: A cloud company says notorious Russian hacker group APT29 attacked it, Chinese hackers use ransomware to hide their espionage campaigns, and a bank popular with startups discloses a cyberattack.

WIRED learned this week that Amazon Web Services investigated claims that the AI search startup Perplexity may have violated the cloud company's rules by appearing to pull data from websites that have attempted to shield themselves from such scraping. The news comes after WIRED published findings last week about the AI search chatbot's indiscriminate data-scraping practices and questionable content generation. WIRED's inquiries to AWS about the matter spurred it to look at Perplexity's activities. A separate WIRED investigation into Quora's Poe AI platform found that it downloaded entire articles from a variety of publishers and shared the files with users, effectively circumventing paywalls.

The US Justice Department announced convictions earlier this week related to a series of violent home invasions in which more than a dozen men threatened, assaulted, tortured, or kidnapped 11 people as part of efforts to steal cryptocurrency.

On Wednesday, WikiLeaks founder Julian Assange agreed to plead guilty to one count of espionage in US court, finally concluding a protracted legal battle between the US government and the controversial, anonymity-focused publisher. The American Privacy Rights Act—the latest in an endless parade of “comprehensive” US privacy bills—got pulled from a congressional hearing and is now unlikely to receive a full vote. And a new tailor-built platform created by the firm SITU Research has been used for the first time in the International Criminal Court as a tool for prosecuting a war crimes case.

Concrete proof is finally starting to emerge from San Jose and New York City that AI gunshot detection systems operate substantially below their advertised accuracy rates. Deepfake creators are revictimizing individuals from the GirlsDoPorn sex trafficking operation by hosting altered versions of videos from that platform. And bureaucratic hurdles are making it even more difficult for health care providers like hospitals to recover and come back online after ransomware attacks.

But wait, there's more. Each week, we round up the security news we didn’t cover in depth ourselves. Click the headlines to read the full stories, and stay safe out there.

**Google Is Piloting a Face-Recognition Office Security System**

At its campus in Kirkland, Washington, Google is rolling out a face recognition system to detect “unauthorized individuals” and block their access to its offices, according to a document about the plan viewed by CNBC. Security cameras inside Google spaces have already been collecting face data and comparing it to employee badge photos in an attempt to flag people who are not regular employees or part of the broader Google workforce. If the system identifies a person of interest, Google’s “Security and Resilience Services” team will work to identify would-be intruders “who may pose a security risk to Google’s people, products, or locations,” according to the document. People who work at or visit the Kirkland campus will not be able to opt out of having their face data collected by the system, but the document notes that data is collected “strictly for immediate use and not stored.” It adds that employees can opt out of having their badge images stored by Google and that this cache of images is only being used to test the system. The document says that the goal of the program is to “maintain safety and security of our people and spaces.”

**German Cloud Company Says It Was the Target of Russian “Cozy Bear” Hackers**

The German cloud company Teamviewer confirmed on Friday that it suffered a cyberattack earlier this week. The company accused the notorious Russian hacking group APT29—also called “Cozy Bear” and “Midnight Blizzard”—of carrying out the attack. “Current findings of the investigation point to an attack on Wednesday, June 26, tied to credentials of a standard employee account within our Corporate IT environment,” Teamviewer said in a statement. The company later confirmed that “the attack was contained within TeamViewer’s internal corporate IT environment and did not touch the product environment, our connectivity platform, or any customer data.”

**Chinese Hackers Have Been Using Ransomware Attacks to Mask Their Activities**

Suspected Chinese government-backed hackers, including the group known as “ChamelGang,” have deployed ransomware in dozens of high-profile attacks as a distraction while they conduct espionage operations on victims' networks. Researchers from the security firms SentinelOne, Recorded Future, and TeamT5 have found evidence, for example, that attackers used the tactic in hacks of a critical Indian health care platform and Brazil's presidential office. Espionage actors are participating in “an increasingly disturbing trend of using ransomware as a final stage in their operations for the purposes of financial gain, disruption, distraction, misattribution, or removal of evidence,” the researchers wrote.

**Evolve Bank, Used by Startups, Confirms LockBit Ransomware Attack**

On Wednesday, Evolve Bank and Trust, a financial firm popular with fintech startups, confirmed that it was the victim of a ransomware attack and data breach that may impact customers. “Evolve is currently investigating a cybersecurity incident involving a known cybercriminal organization that appears to have illegally obtained and released on the dark web the data and personal information of some Evolve retail bank customers and financial technology partners’ customers,” the bank said in a statement on Wednesday. The prolific and aggressive ransomware gang known as LockBit recently posted data on its dark-web leak site that it claimed had been stolen from Evolve.

Google Is Piloting Face Recognition for Office Security

PRESS RELEASE

BROWNWOOD, Texas, June 26, 2024 /PRNewswire/ -- Landmark Admin, LLC ("Landmark"), is providing notice of a recent data security incident. Landmark is a third-party administrator for life insurance carriers and may have received certain personal information from producers, insureds, policy owners or policy beneficiaries for insurance policies which Landmark administered.

What Happened?

On or about May 13, 2024, Landmark detected suspicious activity on its system and later learned that an unauthorized third party accessed its network. Upon discovery of this incident, Landmark immediately disconnected indicated systems and remote access to the network and promptly engaged a specialized third-party cybersecurity firm and IT personnel to assist with securing the environment, as well as to conduct a comprehensive forensic investigation to determine the nature and scope of the incident. While the forensic investigation remains ongoing, Landmark found evidence to suggest some of its files may have been compromised by an unauthorized third-party.

Based on these findings, Landmark began reviewing the affected systems to identify the specific individuals and the types of information that may have been compromised.

What Information Was Impacted? 

The following information may have been subject to unauthorized access: first name/initial and last name; address; Social Security number; tax identification number; driver's license number/state-issued identification card; passport number; financial account number; medical information; date of birth; health insurance policy number; and life and annuity policy information.

The information varies by individual. Affected individuals will be notified by mail of information that was impacted.

What Remediation Measures Were Taken?

Landmark takes the privacy and security of personal information seriously. Since the discovery, Landmark moved quickly to investigate and secure its systems. Landmark has taken steps to further enhance its network security, and took steps, and will continue to take steps, to mitigate the risk of future harm.

What Steps Can Individuals Take?

Landmark encourages everyone to remain vigilant against incidents of identity theft by reviewing their account statements and monitoring their credit reports for any suspicious activity. Individuals can obtain free copies of their credit reports by going to the following website: www.annualcreditreport.com or by calling them toll-free at 1-877-322-8228. (Hearing impaired consumers can access their TDD service at 1-877-730-4204.)

You can also obtain more information from the Federal Trade Commission (FTC) about identity theft and ways to protect yourself. The FTC has an identity theft hotline: 877-438-4338; TTY: 1-866-653-4261. They also provide information on-line at www.ftc.gov/idtheft.

Other Important Information: 

If you have questions about the Incident not addressed in this notice please call the help line at 1-844-428-5109 and representatives are available for 90 days from the date of this letter to assist you between the hours of 8:00 a.m. to 8:00 p.m. Eastern time, Monday through Friday excluding U.S. holidays.

Landmark sincerely regrets any concern or inconvenience this matter may cause and remains dedicated to ensuring the privacy and security of all information in our control.

Landmark Admin, LLC Provides Notice of Data Privacy Incident

Despite warnings from Health-ISAC and the NCC Group, the remote access software maker says defense-in-depth kept customers' data safe from Midnight Blizzard.

Source: Tuta via Alamy Stock Photo

This week, TeamViewer said that while the Russian group APT29, aka Midnight Blizzard, managed to access its corporate network, the threat actors were limited to the company's internal IT network because of "strong segmentation" between its environments. Thus, no customers were affected.

In public statements on June 27 (reiterated today), the German maker of remote desktop software said, "\[W\]e keep all servers, networks, and accounts strictly separate to help prevent unauthorized access and lateral movement between the different environments. This segregation is one of multiple layers of protection in our 'defense in-depth' approach."

Defense-in-depth is a set of basic techniques, including network segmentation, that the US government consistently urges people to implement. Others include network monitoring, multifactor authentication, and access control lists.

Even so, because of the potential mischief a bad actor with desktop access can wreak, TeamViewer users should up their security game, according to industry groups. The NCC Group, which originally issued a warning under an amber/limited classification but then changed it to green/public, advised its customers that, while awaiting final confirmation of the extent of compromise, they remove TeamViewer from their systems if possible and closely monitor hosts that had the application installed if not.

The Health Information Sharing and Analysis Center (H-ISAC) meanwhile issued similar advice to the healthcare sector, adding that organizations should implement two-factor authentication (2FA) and allowlists/blocklists to control who gets to access systems via TeamViewer.

Stakes are particularly high for remote access application security because of the legitimate access to users' systems such software provides. In January, Huntress reported that two hacking attempts started with TeamViewer instances, and there is a long history of attackers using remote desktop software to implant malware. The apparently limited impact of the latest incident shows the value of defense-in-depth techniques to limit the effect of intrusions.

**About the Author(s)**

TeamViewer Credits Network Segmentation for Rebuffing APT29 Attack

PRESS RELEASE

SAN FRANCISCO, June 26, 2024 /PRNewswire/ -- Ballistic Ventures, the venture capital firm dedicated exclusively to funding and incubating entrepreneurs and innovations in cybersecurity, is pleased to announce that co-founder Kevin Mandia is now General Partner.

Mandia is one of the world's most recognized experts in cybersecurity, known for his relentless efforts to fight cyber threats for more than 30 years. In 2004, he founded renowned cybersecurity firm Mandiant, serving as CEO from 2004 to 2013, when Mandiant Corporation was acquired by FireEye. Mandia took the helm as CEO of FireEye in 2016, guiding the company through a divestiture and corporate name change to Mandiant, Inc. in 2021, and through a successful acquisition by Google in 2022. Mandia recently transitioned to an advisory role within Google Cloud, and he continues to sit on the Google Public Sector board.

In 2023, Mandia was appointed by President Biden to serve as a member of the National Security Telecommunications Advisory Committee (NSTAC). He is also a member of the Cybersecurity and Infrastructure Security Agency (CISA) Cybersecurity Advisory Committee. Previously, he held senior positions in the security consulting divisions of Sytex, acquired by Lockheed Martin, and Foundstone, acquired by McAfee. He also served in the United States Air Force as a computer security officer at the Pentagon, and later as a special agent in the Air Force Office of Special Investigations.

"I am very excited to dedicate more of my energy to Ballistic Ventures, and I especially look forward to working with the entrepreneurs who are shaping the future of cybersecurity," said Mandia.

Ballistic Ventures was co-founded in 2021 by Mandia and General Partners Barmak Meftah, Ted Schlein, Jake Seid and Roger Thornton. While CEO of Mandiant (now part of Google Cloud), Mandia jointly served as Co-founder and Strategic Partner at Ballistic, leading the firm's investment in SpecterOps, the Attack Path Management company, where he is an Observer to the company's Board of Directors. Mandia also served as the second investing partner for five of the VC firm's 18 investments to date, and is a Board Observer to portfolio company Alethea, the disinformation detection and mitigation company.

"We're excited to have Kevin as a General Partner at Ballistic," said Schlein. "Kevin's expertise in the cybersecurity industry is unparalleled, and his knowledge of the market and customer set is unmatched."

As General Partner, Mandia will draw from his extensive knowledge of the threat landscape and expertise as a successful founder and CEO to expand his investments within the firm and continue to mentor entrepreneurs and scale companies across the Ballistic portfolio.

Mandia's move to General Partner comes on the heels of Ballistic Ventures announcing the close of its $360 million oversubscribed second fund. The firm is actively looking to deploy the new capital in novel innovations led by passionate cybersecurity entrepreneurs.

About Ballistic Ventures  
Ballistic Ventures is a venture capital firm solely dedicated to early-stage cybersecurity and cyber-related companies. The partners have spent their entire careers defending against every cyber threat conceivable. Members of the firm have founded, operated, and funded over 100 successful cybersecurity firms – including Abnormal Security, AlienVault, ArcSight, Fortify, Mandiant, and Shape Security – led over 10,000 security professionals globally, and have 40+ years of experience in venture capital. The Ballistic portfolio includes Aembit, Alethea, ArmorCode, AuthMind, Codezero, Concentric AI, Mimic, Nudge Security, Oligo, Pangea, Perygee, Reach Security, SpecterOps, Talon (PANW), Veza and WitnessAI. Our experience provides entrepreneurs impactful support from people focused on the same mission. Our networks and relationships open doors for our founders. Learn more at ballisticventures.com.

Cybersecurity Veteran Kevin Mandia Named General Partner of Ballistic Ventures

### Summary
Missing limit for accepted NTS-KE connections allows an unauthenticated remote attacker to crash ntpd-rs when an NTS-KE server is configured. Non NTS-KE server configurations, such as the default ntpd-rs configuration, are unaffected.

### Details
Operating systems have a limit for the number of open file descriptors (which includes sockets) in a single process, e.g. 1024 on Linux by default. When ntpd-rs is configured as an NTS server, it accepts TCP connections for the NTS-KE service. If the process has reached the descriptor limit and tries to accept a new TCP connection, the accept() system call will return with the EMFILE error and cause ntpd-rs to abort.

A remote attacker can open a large number of parallel TCP connections to the server to trigger this crash. The connections need to be opened quickly enough to avoid the `key-exchange-timeout-ms` timeout (by default 1000 milliseconds).

### Impact
Only NTS-KE server configuration are affected. Those without an NTS-KE server configuration such as NTS client only or NTP only configuration are unaffected. For affected configurations the ntpd-rs daemon can made completely unavailable by crashing the service. If ntpd-rs is automatically restarted, an attacker can repeat the attack to prevent ntpd-rs from doing anything useful.

### Workarounds
- Disable NTS-KE server functionality
- Increase system resource limits (`RLIMIT_NOFILE`) to make the attack more difficult
- Lower the `key-exchange-timeout-ms` configuration setting to make the attack more difficult

**Summary**

Missing limit for accepted NTS-KE connections allows an unauthenticated remote attacker to crash ntpd-rs when an NTS-KE server is configured. Non NTS-KE server configurations, such as the default ntpd-rs configuration, are unaffected.

**Details**

Operating systems have a limit for the number of open file descriptors (which includes sockets) in a single process, e.g. 1024 on Linux by default. When ntpd-rs is configured as an NTS server, it accepts TCP connections for the NTS-KE service. If the process has reached the descriptor limit and tries to accept a new TCP connection, the accept() system call will return with the EMFILE error and cause ntpd-rs to abort.

A remote attacker can open a large number of parallel TCP connections to the server to trigger this crash. The connections need to be opened quickly enough to avoid the key-exchange-timeout-ms timeout (by default 1000 milliseconds).

**Impact**

Only NTS-KE server configuration are affected. Those without an NTS-KE server configuration such as NTS client only or NTP only configuration are unaffected. For affected configurations the ntpd-rs daemon can made completely unavailable by crashing the service. If ntpd-rs is automatically restarted, an attacker can repeat the attack to prevent ntpd-rs from doing anything useful.

**Workarounds**

*   Disable NTS-KE server functionality
*   Increase system resource limits (RLIMIT_NOFILE) to make the attack more difficult
*   Lower the key-exchange-timeout-ms configuration setting to make the attack more difficult

**References**

*   GHSA-2xpx-vcmq-5f72
*   pendulum-project/ntpd-rs@6049687

GHSA-2xpx-vcmq-5f72: Unlimited number of NTS-KE connections can crash ntpd-rs server

The company is urging users running vulnerable versions to patch CVE-2024-5655 immediately, to avoid CI/CD malfeasance.

Source: Bill Crump via Alamy Stock Photo

A critical GitLab vulnerability could allow an attacker to run a pipeline as another user.

GitLab is a popular Git repository, second only to GitHub, with millions of active users. This week, it released new versions of its Community (open source) and Enterprise Editions.

The updates include fixes for 14 different security issues, including cross site request forgery (CSRF), cross site scripting (XSS), denial of service (DoS), and more. One of the issues is deemed of low severity according to the Common Vulnerability Scoring System (CVSS), nine are of medium severity, and three are high — but there's also one critical bug with a CVSS score of 9.6 out of 10.

**CVE-2024-5655 Offers Critical Threat to Code Development**

That critical one, CVE-2024-5655, affects GitLab versions starting from 15.8 prior to 16.11.5, starting from 17.0 prior to 17.0.3, and starting from 17.1 prior to 17.1.1, according to the company. It enables an attacker to trigger a pipeline as another user, but only under circumstances which GitLab did not elaborate on (nor did it provide any other information about the vulnerability).

A pipeline automates the process of building, testing, and deploying code in GitLab. Theoretically, an attacker with the ability to run pipelines as other users can access their private repositories, and manipulate, steal, or exfiltrate sensitive code and data contained therein.

Unlike with CVE-2023-7028 — a 10 out of 10 account takeover bug known to have been exploited earlier this Spring — GitLab has thus far found no evidence of CVE-2024-5655 exploits in the wild. Though, that could quickly change.

**A Compliance Issue, Not Just Security**

 Issues rooted deep in the development process like CVE-2024-5655 can sometimes cause headaches beyond the simple risk they pose on paper.

"In a worst-case scenario, this vulnerability doesn't even have to be exploited to cost companies money in lost revenue," says Jamie Boote, associate principal consultant at Synopsys Software Integrity Group. The mere fact that a software or software-driven product was built using a vulnerable version of GitLab could itself be cause for concern.

"Pipeline vulnerabilities like this can not only pose a security risk but a regulatory and compliance risk as well. As US companies are working towards compliance with the Self-Attestation Form requirements that they need to meet to sell software and products to the US Government, not addressing this vulnerability could lead to a compliance gap which could put sales and contracts at risk," he explains. In particular, he points to line item 1c in Section III of the US Department of Commerce's Secure Software Development Attestation Form Instructions, which requires "Enforcing multi-factor authentication and conditional access across the environments relevant to developing and building software in a manner that minimizes security risk."

"Compliance with item 1c is in jeopardy for companies who don't address this vulnerability as an exploit would allow attackers to bypass those conditional access controls that companies are relying on for compliance," he concludes.

**About the Author(s)**

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.

Critical GitLab Bug Threatens Software Development Pipelines

Our collection of the most relevant reporting and industry perspectives for those guiding cybersecurity strategies and focused on SecOps.

Welcome to CISO Corner, Dark Reading's weekly digest of articles tailored specifically to security operations readers and security leaders. Every week, we'll offer articles gleaned from across our news operation, The Edge, DR Technology, DR Global, and our Commentary section. We're committed to bringing you a diverse set of perspectives to support the job of operationalizing cybersecurity strategies, for leaders at organizations of all shapes and sizes.

**Your Phone's 5G Connection Is Vulnerable to Bypass, DoS Attacks**

By Nate Nelson, Contributing Writer, Dark Reading

Wireless service providers prioritize uptime and lag time, occasionally at the cost of security, allowing attackers to take advantage, steal data, and worse.

At the upcoming Black Hat 2024 in Las Vegas, a team of seven Penn State University researchers will describe how hackers can go beyond sniffing your Internet traffic by literally providing your Internet connection to you (over 5G). From there, spying, phishing, and plenty more are all on the table.

The Penn State researchers have reported all the vulnerabilities they discovered to the respective 5G mobile vendors, which have all since deployed patches.

A more permanent solution, however, would have to begin with securing 5G authentication. As Hussain says, "If you want to ensure the authenticity of these broadcast messages, you need to use public key infrastructure (PKI). And deploying PKI is expensive — you need to update all of the cell towers. And there are some non-technical challenges. For example, who will be the root certificate authority of the public keys?"

Read more: Your Phone's 5G Connection Is Vulnerable to Bypass, DoS Attacks

Related: Black Hat USA 2024 Sessions Agenda

**Dark Reading Confidential: Meet the Ransomware Negotiators**

Episode 2: Incident response experts-turned-ransomware negotiators Ed Dubrovsky, COO and managing partner of CYPFER, and Joe Tarraf, chief delivery officer of Surefire Cyber, explain how they interact with cyber threat actors who hold victim organizations' systems and data for ransom. Among their fascinating stories: how they negotiated with cybercriminals to restore operations in a hospital NICU where lives were at stake, and how they helped a church, where the attackers themselves "got a little religion."

Listen now: Meet the Ransomware Negotiators

Visit the podcast archive, available here.

**DR Global: China-Linked Cyber-Espionage Teams Target Asian Telecoms**

By Robert Lemos, Contributing Writer, Dark Reading

In the latest breaches, threat groups compromised telecommunications firms in at least two Asian nations, installing backdoors and possibly eavesdropping or pre-positioning for a future attack.

Tools from a trio of China-linked groups — Fireant, Neeedleminer, and Firefly — were used to compromise telecommunications companies in at least two Asian nations, according to an analysis published by technology giant Broadcom's Symantec cybersecurity division. The groups — also known as Mustang Panda, Nomad Panda, and Naikon, respectively — previously have been associated with widespread attacks against a variety of countries in the Asia-Pacific region.

Attackers see telecommunications companies as a strong launchpad from which to compromise other systems, eavesdrop on communications, or cybercrime

"There's the potential for eavesdropping and surveillance but also, because telecoms is critical infrastructure, you could create significant disruption in your target country," says Dick O'Brien, principal threat intelligence analyst for Symantec's threat hunter team. "We think that there is a distinct possibility that the motive for these attacks was similar to what the US government has been repeatedly warning about."

Read more: China-Linked Cyber-Espionage Teams Target Asian Telecoms

Related: Japan, Philippines & US Forge Cyber Threat Intel-Sharing Alliance

**Key Takeaways From the British Library Cyberattack**

Commentary by Steve Durbin, CEO, Information Security Forum

Knowledge institutions with legacy infrastructure, limited resources, and digitized intellectual property must protect themselves from sophisticated and destructive cyberattacks.

In October 2023, the British Library underwent a crippling cyberattack that cost the library £7 million (US$8.9 million) in recovery costs, or about 40% of its reserve budget. Although the online catalogue was restored in January, full recovery is not expected before the end of the year.

The British Library ransomware attack is a wake-up call for all knowledge institutions, libraries, and government-funded organizations that have similar risks in terms of legacy infrastructure, limited resources, and a significant portion of their intellectual property and research existing in a digital format. Such organizations should follow best practices to help protect themselves from sophisticated and destructive cyberattacks.

The institution issued a report outlining details of the attack and sharing valuable lessons, which include:

1.  Assess your technical debt;
    
2.  Maintain a holistic view of cyber-risk;
    
3.  Practice good information governance;
    
4.  And, adopt a defense-in-depth approach.
    

Read more on the lessons learned: Key Takeaways From the British Library Cyberattack

Related: Enhancing Incident Response Playbooks With Machine Learning

**The NYSE's $10M Wake-up Call**

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

The settlement between the SEC and the owner of the New York Stock Exchange is a critical reminder of the vulnerabilities within financial institutions' cybersecurity frameworks as well as the importance of regulatory oversight.

In 2018, a severe cyberattack on a subsidiary of Intercontinental Exchange Inc. (ICE), the owner of the New York Stock Exchange (NYSE), exposed highly sensitive information. The SEC's subsequent investigation revealed that ICE failed to implement adequate cybersecurity measures, compromising its systems.

As a result, ICE was required to pay a $10 million settlement. This incident is a stark reminder of the critical need for robust cybersecurity practices, particularly for entities handling such vital financial data.

The primary accountability lies with ICE, which neglected to enforce stringent cybersecurity protocols. The SEC's findings indicate that ICE's subsidiary had multiple vulnerabilities that must be addressed adequately. This lack of preparedness is a significant breach of fiduciary duty to protect sensitive financial information.

However, the $10 million fine, while significant, raises questions about whether it is enough to deter future negligence by major financial institutions.

Read more: The NYSE's $10M Wake-up Call

Related:  Don't Forget to Report a Breach: A Cautionary Tale

**CISA Releases Guidance on Network Access, VPNs**

By DR Techology Staff

CISA outlines how modern cybersecurity relies on network visibility to defend against threats and scams.

The Cybersecurity and Infrastructure Security Agency (CISA), along with the Federal Bureau of Investigation (FBI) and similar entities in New Zealand, has issued guidance on modern approaches to network access security.

With the growing number of breaches and data incidents, organizations need to be thinking about, and planning to adopt, modern firewall and network access management technologies to gain visibility over the network.

CISA lays out three specific approaches its guidance: zero trust, secure service edge (SSE), and secure access service edge (SASE).

Read more: CISA Releases Guidance on Network Access, VPNs

Related: Attackers Target Check Point VPNs to Access Corporate Networks

CISO Corner: The NYSE &amp; the SEC; Ransomware Negotiation Tips

Despite more than 50% of all open source code being written in memory-unsafe languages like C++, we are unlikely to see a massive overhaul to code bases anytime soon.

A comprehensive new study has unearthed fresh details on the extensive and troubling use of memory-unsafe code in major open source software (OSS) projects.

However, the chances that fresh insight on a long known issue will spur any immediate changes to the software landscape remain bleak, given just how enormous, costly, and complex the task is of rewriting codebases entirely in memory-safe code.

Memory-unsafe programming languages such as C and C++ allow programmers to have more direct control over memory-related functions in code, which can often lead to very common application security issues like buffer overflows and use-after-free errors. Such flaws represent a large proportion of all vulnerabilities in modern application software. In contrast, memory-safe languages — the most common examples of which include Rust, Python, Java, and Go —offer guardrails such as built-in runtime and compile time checks to mitigate against common memory related errors.

**Most OSS Projects Contain Memory-Unsafe Code**

The US Cybersecurity and Infrastructure Security Agency (CISA) along with the FBI and counterparts at the Australian Cyber Security Centre and the Canadian Centre for Cyber Security this week released a report summarizing the results of their investigation into the use of memory-unsafe code in OSS.

The findings, while troubling, are not entirely unexpected given past data on the extensive use of memory-unsafe languages in almost all modern codebases. Fifty-two percent of the 172 major open source projects that the research authors looked at contained code written in a memory-unsafe language. More than half (55%) of the total lines of code in all the projects combined were written in a memory-unsafe language, with the larger projects being the worst culprits.

Some 95% of the total lines of code in Linux for instance are memory-unsafe. For MySQL Server, that number was 84%; for TensorFlow it was 64%; for Zephyr 84%; and for Chromium 51%. On average, 26% of the total lines of code in the 10 largest open source projects consisted of memory-unsafe code. Even projects written in memory-safe languages were at risk from dependencies on unsafe components.

"Most critical open source projects analyzed, even those written in memory-safe languages, potentially contain memory safety vulnerabilities," the report noted. "This can be caused by direct use of memory-unsafe languages or external dependency on projects that use memory-unsafe languages."

In addition, the tendency — and often the need — to disable memory-safety features to accommodate functional requirements in applications can often neutralize the benefits of using otherwise memory-safe languages.  

"These limitations highlight the need for continued diligent use of memory safe programming languages, secure coding practices, and security testing," the report authors noted.

**CISA Consistent With Previous OSS Data**

The findings are consistent with numerous previous studies that have examined the extensive problems tied to the use of memory-unsafe languages.  

And indeed, concerns over the ubiquity of the problem have prompted calls for change over the years. The most recent is a February 2024 technical report from the White House that urged industry stakeholders to go back to the building blocks and start over with using memory safe code in all software. In 2022, the US National Security Agency (NSA) urged software makers and all organizations developing software to consider adopting memory-safe languages to reduce risk from memory management related software issues in modern code bases. The continued pounding away at the topic over the years has spurred some change, but most expect it will take years — if not even decades — for a whole scale shift to memory-safe languages to happen.

"Adopting memory-safe code is challenging, primarily because changing a programming language often requires a complete rewrite of existing code," says Neatsun Ziv, CEO and Co-Founder of OX Security. The cost and effort required to undertake such a massive overhaul without significant economic incentives will likely make any change, a slow process.

**Making the World Memory-Safe: A Huge & Complex Challenge**

Omkhar Arasaratnam, general manager at OpenSSF says memory safety issues aren't specifically a problem for either open or closed-source software. It's a problem in general for all modern software.

"There are many memory-safe languages available today like JavaScript, Python, and Java, but software engineers often use memory-unsafe older languages like C/C++ for performance or low-level hardware access," he says.

Also, while Rust has emerged as a viable alternative to C/C++ for low level systems programming in recent years, there are many embedded systems and safety-critical applications for which Rust is not appropriate, he adds.

"While it is certainly possible to write memory-safe code in a memory-unsafe language, 25 years of CVEs tells us it is highly unlikely," Arasaratnam says. "It is not that people are bad programmers, but defensively writing code that is memory-safe in a memory-unsafe language is very difficult," he notes. As newer projects adopt memory-safe languages, expect the use of memory-unsafe languages to decrease over time, in all but niche applications.

Tim Mackey, head of software supply chain risk strategy at Synopsys Software Integrity Group, says the new report does a good job showing how some major open source software projects such as Kubernetes and WordPress are authored in a memory-safe language. However, there are other issues that remain unexplored, he says. For example, it would be interesting to know if memory-safe languages are being used in new projects on GitHub, and whether memory-safe libraries are being used as dependencies in larger projects.

"We can safely say that awareness of memory safe languages is growing, but is it growing at a rate that would displace older languages? For example, are the creators of new embedded software solutions using C++ or Rust, and to what degree?"

**About the Author(s)**

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.

CISA's Flags Memory-Unsafe Code in Major Open Source Projects

Red Hat Security Advisory 2024-4165-03 - An update for pki-core is now available for Red Hat Enterprise Linux 9. Issues addressed include a bypass vulnerability.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_4165.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: pki-core security updateAdvisory ID:        RHSA-2024:4165-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:4165Issue date:         2024-06-27Revision:           03CVE Names:          CVE-2023-4727====================================================================Summary: An update for pki-core is now available for Red Hat Enterprise Linux 9.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:The Public Key Infrastructure (PKI) Core contains fundamental packages required by Red Hat Certificate System.Security Fix(es):* dogtag ca: token authentication bypass vulnerability (CVE-2023-4727)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2023-4727References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2232218https://issues.redhat.com/browse/RHEL-23077

Tag

#auth