A world of increasingly connected devices has created a vast attack surface for sophisticated adversaries.

The explosion in connected devices, ranging from the Internet of Things to networking devices and operational technology (collectively known as the Extended Internet of Things, or xIoT), has created a vast, diverse, and largely unmapped attack surface that sophisticated adversaries are actively exploiting.

This growing risk is reflected in many recent reports from companies like Microsoft, Intel 471, and Zscaler that have found a significant uptick in both targeted and untargeted attacks on these devices, with a high rate of malware infections.

However, these threats — particularly when they target IoT devices — are often misunderstood or dismissed, as companies tend to view them as less significant than a traditional network attack. Part of the reason for this is the mistaken belief that IoT threats are mostly limited to botnet malware used for cryptomining and distributed denial-of-service (DDoS) attacks. In reality, IoT attacks are becoming much more sophisticated and now pose serious threats to corporate network integrity, data security, and even physical security systems.

Here are three xIoT attacks every company should be aware of:

**Pivoting From the xIoT Device**

Since many xIoT devices lack even basic native cybersecurity protections, disallow the installation of traditional endpoint security software, and are often unmonitored, they are an effective initial access point for attackers looking to gain a beachhead on a company and then move laterally across its network.

Once the xIoT device has been compromised, the adversary can use this foothold to upload tools, sniff network traffic, search for other exploitable devices, and exfiltrate sensitive data. For example, an attacker can transition from an IoT device into the main IT network, as well as the operational technology (OT) network.

This type of "pivot attack" has already been observed in the wild by multiple companies. My company has seen a growing number of corporate cyberattacks, in which the company was first compromised through a security camera, door controller, or other device, then targeted with ransomware, espionage, or data theft through its IT network.

In 2019, Microsoft Threat Intelligence Center detected an adversary that exploited three different IoT devices (a VoIP phone, a printer, and a video decoder), from which the actor established a presence on the network while looking for further access. Researchers also unveiled a proof-of-concept ransomware that can spread from an xIoT device to an IT network.

**Atypical Data Theft**

xIoT devices can also be direct targets of espionage and data theft.

Certain office devices like connected printers and document scanners are storehouses of sensitive corporate information that is largely unprotected. In the healthcare industry, CT scanners and MRI machines also contain valuable personal and medical information. Industrial devices can pose data breach risks too. Certain OT devices, like programmable logic controllers (PLCs), can contain privileged manufacturing and processing details, such as temperature and pressure ranges, chemical mixing.

This type of sensitive data storage in xIoT devices is often overlooked by traditional information security audits, and the devices themselves offer little, if any, data protection. For remote attackers, gaining access to these devices is usually a trivial matter.

My company has found that 50% of xIoT devices use default passwords, 68% of devices have high-risk or critical CVEs in their firmware, and 26% of these devices are end-of-life and no longer supported. This means in literally half of these cases, all an attacker needs to do is enter in a default password to gain access to privileged data.

**xIoT as a Persistence Strategy**

Threat actors who have already breached a corporate IT network through traditional means like phishing may also carry out a second-stage attack on xIoT devices to achieve long-term persistence inside the organization.

One example is the threat actor UNC3524, which Mandiant recently discovered had been installing a backdoor called QuietExit in opaque network appliances and IoT devices like security cameras, remaining undetected on victims' networks for at least 18 months.

xIoT devices are an ideal hiding place for sophisticated adversaries. These devices are poorly monitored, lack anti-malware and intrusion detection coverage, and are not easy to analyze during incident response. My company has found that over 80% of security teams can't even identify the majority of xIoT devices they have in their networks. They also fall into an administrative gray area in terms of who is responsible for managing them (is it the IT team, the security team, the operations team, or the vendor?), which leads to confusion and inaction.

An adversary can easily install a backdoor in any one of these overlooked xIoT devices that will be exceedingly difficult for the security team to detect. The average enterprise has anywhere from tens of thousands to millions of xIoT devices, and typically relies on manual processes for monitoring and maintaining them. Detecting such a backdoor will be like trying to find a needle in an enormous haystack (or haystacks).

**Preventing the Full Range of xIoT Attacks**

In spite of their many risks, xIoT devices can be sufficiently protected without imposing high costs on a company.

Basic measures such as strong password management and keeping firmware up to date will drastically reduce the risk. Accurate inventorying and regular monitoring are also key.

Where companies will be challenged is in terms of the volume of devices they must protect. This is why automation is important, as manually changing passwords and updating firmware on such a vast array of devices isn't feasible for most companies.

3 xIoT Attacks Companies Aren't Prepared For

After an uproar, the city board voted to rescind last week's bill to allow police to use robots to deliver deadly force. The fight isn't over, but there's a good reason it should be.

On Nov. 29, the San Francisco Board of Supervisors voted to allow the San Francisco Police Department (SFPD) to use armed robots for lethal force, a month after public outcry caused the police in nearby Oakland to rescind a similar request. A week later, the board voted again — this time to explicitly deny permission for deadly force and send the original bill back to committee. Many questions about that original bill remain unanswered, but one obvious one is: If we allow civilian agencies to arm robots, how do we guard against misuse — by police themselves, yes, but also by unauthorized users?

Security researchers Cesar Cerrudo and Lucas Apa tackled those questions as IOActive consultants back in 2017. The issues are still prevalent today, according to Cerrudo, now an independent cybersecurity researcher.

"As any piece of technology, robots could be hacked; it could be easy or extremely difficult, but possibilities are there," he tells Dark Reading. "In order to reduce hacking possibilities, robot technology has to be built with security in mind from the very beginning and then all the robot technology properly audited to identify all potential vulnerabilities and to eliminate them."  

The categories of vulnerabilities Cerrudo and Apa discovered included insecure communications, authentication issues, missing authorization, weak cryptography, privacy concerns, insecure default configurations, and easily probed open source frameworks.

While the researchers didn't test military or police robots, such machines are likely to be similarly vulnerable. "These robots are some of the most dangerous when hacked, since they are often used to manipulate dangerous devices and materials, such as guns and explosives," they wrote in the paper.

One example of the scale of the danger is a 2007 failure in an automatic anti-aircraft cannon in South Africa that killed nine soldiers and wounded a dozen more in a span of 0.8 seconds. Now imagine what would happen if someone successfully turned an armed police robot back toward the officers or toward the public.

The possibility that robots can be hacked is not so far-fetched. Last year hacktivists gained access to a network of 150,000 surveillance cameras, including those inside of prisons, by obtaining the super admin account information. Hackers have successfully seized control of a Jeep Cherokee driving down a highway and grabbing control of other cars via a key fob hack that has gone mainstream. Even entire buildings have been hacked.

**Taking Back Permission to Kill**

"I simply do not feel arming robots and giving them license to kill will make us safer," said Supervisor Eric Mar on Dec. 6 before voting to send the original bill back to committee.

On Nov. 29, the board had voted 8-3 to approve the bill allowing deadly force; on Dec. 6, the vote was 8-3 to rescind it. "It was a rare step," the San Francisco Chronicle reported. "The board's second votes on local laws are typically formalities that don't change anything."

What does change things in San Francisco is public protest. "We've all heard from a lot of constituents ... on the idea that we as a city will have robots deliver deadly force," said Supervisor Dean Preston at the Dec. 6 meeting.

Three of the supervisors — Shamann Walton (also board president), Hillary Ronen, and Preston — attended one such protest at city hall on Monday, organized by the Quakers, where a crowd held placards reading "no killer robots." 

"We will fight this legislatively at the board, we will fight this in the streets and on public opinion, and if necessary, we will fight this at the ballot," Preston said. That last threat might have been the most persuasive; city voters are not afraid to govern directly through ballot initiatives.

The SFPD has about a dozen robots purchased between 2010 and 2017, the department said in a statement. 

"The robots are remotely controlled and operated by SFPD officers who have undergone specialized training," according to the statement. "Our robots are primarily used in EOD/bomb situations, hazardous materials incidents, and other incidents where officers may need to keep a safe distance before rendering a scene secure."

The SFPD statement continued: "In extreme circumstances, robots could be used to deliver an explosive charge to breach a structure containing a violent or armed subject. The charge would be used to incapacitate or disorient a violent, armed, or dangerous subject who presents a risk of loss of life," although such use "could potentially cause injury or be lethal."

While the Dec. 6 vote was a setback for the SFPD, the San Francisco Standard pointed out that the issue isn't necessarily finalized. The rules committee might be able to sit on it long enough that public attention fades, or they could come up with language that lets a majority of supervisors return their support. But for now, murderbots are explicitly forbidden, and it seems decided.

**Not the First Robo-Cops**

Unmanned aerial vehicles (UAV) have been part of military tactics for half a century, and there are several examples of police departments using remotely operated drones. In 2015, North Dakota legalized arming drones with less-than-lethal weapons like tasers. Of course, tasers can be lethal, and drones are notoriously vulnerable to hacking.

Another prominent police use of unmanned robotics was the NYPD's failed Digidog experiment in 2020-2021, which sent remote-controlled Boston Dynamics robots into dangerous situations, such as standoffs and hostage situations, to minimize risk to personnel. Public reaction to the spidery, fast-moving, stair-climbing robots was so negative, however, that the department ended the contract early.

Proponents of unmanned mobile equipment usually base the technology's mission on saving lives, whether of hostages or police. Indeed, the SFPD's statement asserted, "Robots equipped in this manner would only be used to save or prevent further loss of innocent lives." We have already seen how that plays out in real life.

**Police Robots Have Already Killed**

American police have already used a robot to deliver lethal force. Dallas PD sent a robot rigged with explosives to kill Micah Johnson back in 2016, ending a standoff after Johnson shot 12 Dallas officers, killing five. A grand jury cleared the police of any wrongdoing in that incident, where the police used the ruse of sending the shooter a phone to get the robot close enough. Some of the SFPD's dozen existing robots are "wheeled bomb-disposal robots with extending arms similar to the one used by Dallas officers in 2016," according to the Washington Post.

After that 2016 Dallas use of force, UC Davis law professor Elizabeth E. Joh wrote in the New York Times: "And a robot is unlike a gun in that a gun may misfire, but it can't be hacked. The market for police robots is emerging, but we as a society — and that includes the police — should be wary of any armed police robot that is vulnerable to takeover by third parties. Experience with the security of electronic devices doesn't inspire confidence: If third parties can hack cars or toy drones, they can certainly hack police robots."

Cerrudo's assessment aligns with that warning. 

"If I were to deploy these robots, I would make sure that they were built with security in mind and that they have been properly security-audited by experts," he says. "Failing to do this is exposing the robots to possible cyberattacks that could turn a robot into a dangerous weapon."

San Francisco Rolls Back Its Plan for Killer Robots

Cisco's annual Security Outcomes Report shows executive support for a security culture is growing. It identifies the top seven success factors that boost enterprise security resilience, with a focus on cultural, environmental, and solution-based factors that businesses leverage to achieve security.

**MELBOURNE, Australia, Dec. 6, 2022 /PRNewswire/** — Cybersecurity resilience is a top priority for companies as they look to defend against a rapidly evolving threat landscape, according to the latest edition of Cisco's annual Security Outcomes Report launched today.

Resilience has emerged as a top priority as a staggering 62 percent of organizations surveyed said they had experienced a security event that impacted business in the past two years. The leading types of incidents were network or data breaches (51.5 percent), network or system outages (51.1 percent), ransomware events (46.7 percent) and distributed denial of service attacks (46.4 percent).  

These incidents resulted in severe repercussions for the companies that experienced them, along with the ecosystem of organizations they do business with. The leading impacts cited include IT and communications interruption (62.6 percent), supply chain disruption (43 percent), impaired internal operations (41.4 percent) and lasting brand damage (39.7 percent).

With stakes this high, it is no surprise that 96 percent of executives surveyed for the report said that security resilience is high priority for them. The findings further highlight that the main objectives of security resilience for security leaders and their teams are to prevent incidents, and mitigate losses when they occur.

"Technology is transforming businesses at a scale and speed never seen before. While this is creating new opportunities, it also brings with it challenges, especially on the security front. To be able to tackle these effectively, companies need the ability to anticipate, identify, and withstand cyber threats, and if breached be able to rapidly recover from one. That is what building resilience is all about," said Helen Patton, CISO, Cisco Security Business Group.

"Security, after all, is a risk business. As companies don't secure everything, everywhere, security resilience allows them to focus their security resources on the pieces of the business that add the most value to an organization, and ensure that value is protected," she added.

**Seven Success Factors of Security Resilience**

This year's report has developed a methodology to generate a security resilience score for the organizations surveyed, and identified seven data-backed success factors. Organizations that had these factors present were among the top 90th percentile of resilient businesses. Conversely, those lacking them placed in the bottom 10th percentile of performers.

The findings of the study underline the fact that security is a human endeavor as leadership, company culture, and resourcing have an oversized impact on resilience:

*   Organizations that report poor security support from the C-suite scored 39 percent lower than those with strong executive support.
*   Businesses that report an excellent security culture scored 46 percent higher on average than those without.
*   Companies that maintain extra internal staffing and resources to respond to incidents resulted in a 15 percent boost in resilient outcomes.

In addition, businesses need to take care to reduce complexity when transitioning from on-premise to fully cloud-based environments:

*   Companies whose technology infrastructures are either mostly on-premise or mostly cloud-based had the highest, and nearly identical, security resilience scores. However, businesses that are in the initial stages of transitioning from an on-premise to a hybrid cloud environment saw scores drop between 8.5 and 14 percent depending on how difficult the hybrid environments were to manage.

Finally, adopting and maturing advanced security solutions has significant impacts to resilient outcomes:

*   Companies that reported implementing a mature Zero Trust model saw a 30 percent increase in resilience score compared to those that had none.
*   Advanced extended detection and response capabilities correlated to an incredible 45 percent increase for organizations over those that report having no detection and response solutions.
*   Converging networking and security into a mature, cloud-delivered secure access services edge boosted security resilience scores by 27 percent.

"The Security Outcomes Reports are a study into what works and what doesn't in cybersecurity. The ultimate goal is to cut through the noise in the market by identifying practices that lead to more secure outcomes for defenders," said Jeetu Patel, executive vice president and general manager of security and collaboration at Cisco. "This year we focused on identifying the key factors that elevate the security resilience of a business to among the very best in the industry."

**Additional Resources:**

*   Report: Security Outcomes Report, Volume 3: Achieving Security Resilience
*   Blog: Cracking the Code to Security Resilience: Lessons from the Latest Cisco Security Outcomes Report

**About Cisco**

Cisco (NASDAQ: CSCO) is the worldwide leader in technology that powers the Internet. Cisco inspires new possibilities by reimagining your applications, securing your data, transforming your infrastructure, and empowering your teams for a global and inclusive future. Discover more on The Newsroom and follow us on Twitter at @Cisco.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company.

SOURCE: Cisco Systems, Inc.

Cybersecurity Resilience Emerges as Top Priority as 62% of Companies Say Security Incidents Impacted Business Operations

The botnet exploits flaws in various routers, firewalls, network-attached storage, webcams, and other products and allows attackers to take over affected systems.

A new botnet is attacking organizations through various vulnerabilities in Internet of Things (IoT) devices from D-Link, Huawei, RealTek, TOTOLink, Zyxel, and more, posing a critical threat that allows attackers to take over vulnerable systems, researchers have found.

The botnet, dubbed Zerobot and written in the Go programming language, includes modules capable of self-replication and self-propagation, as well as attacks for different protocols, a researcher from Fortinet shared in a blog post published Dec. 6.

"Zerobot targets several vulnerabilities to gain access to a device and then downloads a script for further propagation," Fortinet Labs senior antivirus analyst Cara Lin wrote in the post.

So far, researchers have seen two versions of the botnet, one that they began tracking on Nov. 18 and a more sophisticated version that appeared soon after, on Nov. 24, that added a string of new capabilities.

The first version of Zerobot was quite basic, but attackers quickly updated it to include a "selfRepo" module that allows it to reproduce itself and infect more endpoints with different protocols or vulnerabilities, researchers said. The latest version — on which their analysis is based — also includes string obfuscation and a copy file module.

**Attack Mode**

Zerobot initiates an attack by first checking its connection to 1.1.1.1, the DNS resolver server from Cloudflare. It then copies itself onto the targeted device based on the victim's OS type, with different tactics depending on the platform, researchers said.

For Windows, Zerobot copies itself to the "Startup" folder with the filename "FireWall.exe." If the targeted platform is Linux, it has three file paths — "HOME%," "/etc/init/," and "/lib/systemd/system/."

Once it is copied onto the targeted device, Zerobot then sets up an "AntiKill" module to prevent users from disrupting its program once it's started. "This module monitors a particular hex value and uses 'signal.Notify' to intercept any signal sent to terminate or kill the process," Lin wrote.

After initialization, Zerobot starts a connection to its command-and-control (C2) server, ws\[:\]//176\[.\]65\[.\]137\[.\]5/handle, using the WebSocket protocol.

Once it sets up a communication channel, the client waits for a command from the server to unleash any of 21 exploits for various vulnerabilities found in IoT products, as well as some others — including the Java framework vulnerability Spring4Shell, phpAdmin, and F5 Big — "to increase its success rate," Lin wrote.

**Enterprises: Take Immediate Action**

Fortinet included a list of the numerous vulnerabilities that Zerobot exploits, which are found in assorted devices including routers, webcams, network attached storage, firewalls, and other products from a host of well-known manufacturers. 

Lin advised any organization using these devices to update to the latest versions or apply any available patches immediately. Indeed, with businesses losing up to $250 million a year on unwanted botnet attacks, according to a report published last year from Netacea, organizations would be wise to evaluate their environments to discover any device that might be vulnerable to Zerobot, she noted.

"Users should be aware of this new threat, patch any affected systems … running on their network, and actively apply patches as they become available," Lin wrote.

Zerobot Weaponizes Numerous Flaws in Slew of IoT Devices

Microsoft, three others release patches to fix a vulnerability in their respective products that enables such manipulation. Other EDR products potentially are affected as well.

Many trusted endpoint detection and response (EDR) technologies may have a vulnerability in them that gives attackers a way to manipulate the products into erasing virtually any data on installed systems.

Or Yair, a security researcher at SafeBreach who discovered the issue, tested 11 EDR tools from different vendors and found six — from a total of four vendors — were vulnerable. The vulnerable products were Microsoft Windows Defender, Windows Defender for Endpoint, TrendMicro ApexOne, Avast Antivirus, AVG Antivirus, and SentinelOne.

**Formal CVEs and Patches**

Three of the vendors have assigned formal CVE numbers for the bugs and issued patches for them prior to Yair disclosing the issue at the Black Hat Europe conference on Wednesday, Dec 7.

At Black Hat, Yair released proof-of-concept code dubbed Aikido that he developed to demonstrate how a wiper, with just the permissions of an unprivileged user, could manipulate a vulnerable EDR into wiping almost any file on the system, including system files. "We were able to exploit these vulnerabilities in more than 50% of the EDR and AV products we tested, including the default endpoint protection product on Windows," Yair said in a description of his Black Hat talk. "We are lucky to have this discovered prior to real attackers, as these tools and vulnerabilities could have done a lot of damage falling in the wrong hands." He described the wiper as likely being effective against hundreds of millions of endpoints running EDR versions vulnerable to the exploit.

In comments to Dark Reading, Yair says he reported the vulnerability to the affected vendors between July and August. "We then worked closely with them over the next several months on the creation of a fix prior to this publication," he says. "Three of the vendors released new versions of their software or patches to address this vulnerability." He identifies the three vendors as Microsoft, TrendMicro and Gen, the maker of the Avast and AVG products. "As of today, we have not yet received confirmation from SentinelOne about whether they have officially released a fix," he says.

Yair describes the vulnerability as having to do with how some EDR tools delete malicious files. "There are two crucial events in this process of deletion," he says. "There is the time the EDR detects a file as malicious and the time when the file is actually deleted," which sometimes can require a system reboot. Yair says he discovered that between these two events an attacker has the opportunity to use what are known as NTFS junction points to direct the EDR to delete a different file than the one that it identified as malicious.

NTFS junctions points are similar to so-called symbolic links, which are shortcut files to folders and files located elsewhere on a system, except that junctions are used to link directories on different local volumes on a system.

**Triggering the Issue**

Yair says that to trigger the issue on vulnerable systems he first created a malicious file — using the permissions of an unprivileged user — so the EDR would detect and attempt to delete the file. He then found a way to force the EDR to postpone deletion until after reboot, by keeping the malicious file open. His next step was to create a C:\\TEMP\\ directory on the system, make it a junction to a different directory, and rig things so that when the EDR product attempted to delete the malicious file — after reboot — it followed a path to a different file altogether. Yair found he could use the same trick to delete multiple files in different places on a computer by creating one directory shortcut and putting specially crafted paths to targeted files within it, for the EDR product to follow.

Yair says that with some of the tested EDR products, he was not able to do arbitrary file deletion but was able to delete entire folders instead.

The vulnerability affects EDR tools that postpone deletion of malicious files till after a system reboots. In these instances, the EDR product stores the path to the malicious file in some location — that varies by vendor — and uses the path to delete the file after rebooting. Yair says some EDR products don't check if the path to the malicious file leads to the same place after reboot, giving attackers a way to stick a sudden shortcut in the middle of the path. Such vulnerabilities fall into a class known as Time of Check Time of Use (TOCTOU) vulnerabilities, he notes.

Yair says that in most cases, organizations can recover deleted files. So, getting an EDR to delete files on a system by itself, while bad, isn't the worst case. "A deletion is not exactly a wipe," Yair says. To achieve that, Yair designed Aikido so it would overwrite files it had deleted, making them unrecoverable as well.

He says the exploit he developed is an example of an adversary using an opponent's strength against them — just as with the Aikido martial art. Security products, such as EDR tools have super-user rights on systems, and an adversary that is able to abuse them can execute attacks in a virtually undetectable manner. He likens the approach to an adversary turning Israel's famed Iron Dome missile defense system into an attack vector instead.

For Cyberattackers, Popular EDR Tools Can Turn into Destructive Data Wipers

Software firms and the National Security Agency urge developers to move to memory-safe programming languages to eliminate a major source of high-severity flaws.

The software industry is making headway against a group of pernicious vulnerabilities that are responsible for the vast majority of critical, remotely exploitable, and in-the-wild attacks, software-security experts said this week.

The class of vulnerabilities — so-called memory-safety issues — include buffer overflows and use-after-free errors and have accounted for the majority of application security issues disclosed by software companies. Now, the latest data show that the increasing use of memory-safe languages — such as Java, C#, and more recently, Rust — has resulted in a rapid decline of the entire class of vulnerabilities.

Last week, for example, Google revealed that the latest version of the Android operating system has more new code written in memory-safe programing languages — such as Java, Rust, and Kotlin — than memory-unsafe languages such as C and C++, resulting in a drop in memory-safety vulnerabilities from 223 to 85 over the past three years.

"We are continuing to focus on eliminating entire classes of vulnerabilities, focusing on the most severe first," says Jeffrey Vander Stoep, a software engineer at Google. "As memory safety vulnerabilities become more scarce, we anticipate the research community to focus their vulnerability-findings efforts on other classes of vulnerabilities."

    

Memory-safety vulnerabilities are disproportionately severe. Source: Google

For decades, C and C++ have been the workhorse programming languages of the software industry. Yet they lack the memory protections of more modern languages, such as C#, Go, Java, Python, Ruby, Rust, and Swift. The result? Fifty-nine percent of applications written in C++ have high-severity or critical-severity flaws, compared to 9% for JavaScript and 10% for Python, according to application-security firm Veracode's State of Software Security Vol. 11 report.

**Buffer Overflows and Wormable Flaws**

The ease with which programmers can create flawed code has become a major problem for large software companies. Microsoft, for example, found that, up until 2018, memory-safety issues accounted for 70% of the vulnerabilities discovered in the company's software. Overall, memory safety issues have accounted for 60% to 70% of all vulnerabilities across a wide variety of ecosystems, according to 2020 research by software resilience engineer Alex Gaynor.

And because the flaws can easily be exploited to attack applications, they are the root causes behind a significant number of compromises, says Chris Wysopal, chief technology officer of Veracode.

"Memory corruption issues are amongst the highest severity flaws as they often allow attackers to exploit with code execution which allows them to take complete control of the application," he says. "In the worst case scenario this allows the creation of a worm exploit which can go on to attack other instances of the vulnerability."

In its recent blog post on its shift to memory-safe languages for Android development, Google noted that while memory-safety vulnerabilities now only account for 36% of issues disclosed in Android, they account for 86% of the critical security vulnerabilities and 89% of remotely exploitable issues.

**Making the Switch to Safe Languages**

For that reason, Google and others have urged developers to adopt memory-safe languages.

In Google's case, C and C++ now account for just less than half of all new code. In fact, Android 13, the latest version, is the first where the majority of code has been written in memory-safe languages, with Rust replacing C and C++ for many developers. Rust is an efficient programming language focused on creating secure code.

Even the National Security Agency is urging companies to adopt memory-safe programming languages.

Switching to a memory-safe language is not sufficient, however. While the languages do make it harder for programmers to write insecure code, every language has a different level of protection. For that reason, the NSA has also recommended that developers use a variety of application-security tools — from compiler options to static scanners to runtime analysis — to harden applications as much as possible.

"Software analysis tools can detect many instances of memory management issues and operating environment options can also provide some protection, but inherent protections offered by memory safe software languages can prevent or mitigate most memory management issues," the NSA's report stated.

In the end, while memory-safe programming languages are not a standalone solution to the problem of software vulnerabilities, they give guidance to developers who can then avoid some of the most severe programming errors, says Veracode's Wysopal.

"It's hard to generalize and say that there is a lower volume of vulnerabilities in memory safe languages since the way they are used is different," he says. "But if you were using two different languages to accomplish the exact same task, and one was memory safe, you'd expect fewer vulnerabilities in that one and typically less critical vulnerabilities."

Shift to Memory-Safe Languages Gains Momentum

If compiling a software bill of materials seems daunting, attack surface management tools can provide many of the benefits.

A software bill of materials (SBOM) is an important tool enterprise defenders can use to track the impact of software security bugs, manage sane patch management, and protect the integrity of the software supply chain as a whole. Scores of industry leaders say so. The Office of the President of the United States says so.

So why are they not widely used yet? What are software vendors worried about? Do they know something that we don't?

In a recent CISO Forum in Whitehall, London, many CISOs felt that the challenges and speed of change in application security, particularly in a cloud-enabled environment, had left them a little nonplussed and challenged to change their architectural models and thinking to become fully cloud native. In particular, there was a reluctance to let go of legacy control methods such as IP-based access lists and endpoint-based security controls.

**Hesitant to Set Off the SBOM**

There are several interesting possibilities that may be driving the tendency to delay providing SBOMs.

The first is **ignorance of their own supply chain**. It's possible that the vendors don't actually know the origin of some of their software. It is common practice in large development teams and long, complex projects to effectively "black box" entire sections of code.

If that is the case, the fact that the organization may not fully know the origins of its software raises a myriad of concerns. It could indicate anything from bad version tracking to the existence of potentially indispensable employees that hold the fate of the entire company in their coding hands. It's completely understandable that such a company would hesitate to release SBOMs for its products.

Another scenario that might make a company leery of SBOMs is **if the product is almost entirely an assembly of other products**. It's the reality of modern software development that programs are the result of custom code cobbled together with third-party libraries and components. If the company has written a very low percentage of its own code, then the SBOM could essentially become a recipe card for someone else to clone the product.

But the likely scenario is that software firms may **see no upside, only potential downside** to releasing SBOMs. Currently there's very little market pressure on releasing SBOMs for their product lines. They may have created one for internal use, but there is no real push to make them public. The main concern voiced by CISOs is that while an SBOM may improve visibility, it provides little impetus towards remediation and no liability for fixing software flaws — leaving the problem squarely in the lap of the end user, the CISO.

**Getting Past the SBOM**

It's unlikely that the industry or the purchasing public will be able to generate the market pressure required to force every major player to release an SBOM for all their products. In May 2021, the US government issued an executive order to improve the nation's cybersecurity that explicitly called for SBOMs as a control measure for the software supply chain. The EU government, for its part, has planned a Cyber Resilience proposal to echo and support the requirements of the US order.

If the main purpose of an SBOM is patch management and vulnerability attribution, there is a secondary layer of monitoring and protection that cybersecurity personnel should be looking at: attack surface management (ASM).

While it would be slightly easier for enterprise security teams to know that the software they use contain packages X, Y, and Z, that isn't the only way to manage application security. By tracking the security advisory history of these software suites, we can estimate the most likely attack vectors that they can fall victim to.

The combination of these vulnerabilities compiled from every piece of software that a company uses makes up an organization's attack surface. What ASM tries to do is intelligently categorize these weaknesses and automate the discovery, remediation, and continuous monitoring of new threats.

It's like tying together a vulnerability advisory service with an enterprise software management solution. The way that the ASM does this varies from product to product, but generally some amount of machine learning is involved. That way predictive models can be built so that when certain zero-day exploits are discovered, you will know how likely they are to apply to your attack surface even if you don't have a detailed SBOM from every vendor.

A good ASM has the additional benefit of treating ducks like ducks. You know: If it looks like a duck and quacks like a duck, it doesn't really matter if someone else labeled it as a swan instead. The ASM only cares about results. If a company insists that it's using the Open Dynamics Engine, but for some mysterious reason it falls victim to all the same vulnerabilities as the PhysX engine, ASM will completely ignore labels and suggest the fixes that actually fit the situation and not the ones that correspond to the names.

Even if the movement toward mainstream adoption of SBOM continues to be slow, security professionals have a strong alternative with ASM. It's also worth noting that ASM will complement any SBOM-based software governance with a dynamic risk mitigation system.

Instead of adopting and deploying something locally to cover your vulnerability discovery and monitoring needs, another alternative is to embrace an agentless security model that can monitor extended asset attack surfaces. The device intelligence firm Armis, for example, does this with a fully cloud-native approach. Think of it as an ASM solution that covers IoT devices, cloud instances, and edge networking setups, as well as traditional on-premises.

Such a model presents a different, more global way of looking at asset intelligence that might be more attractive to large enterprise operations. Smaller operations, however, would likely want to save their money for a good ASM and rely on extra vigilance for their extended network devices.

ASM Can Fill Gaps While Working to Implement SBOM

**BERKELEY, Calif.****,** **Dec. 6, 2022** **/PRNewswire/ --** In a report released today, The Cambridge Centre for Risk Studies (CCRS) and Kivu Consulting, Inc. have combined efforts to research and benchmark cost-effective responses to cybercrime. The research report, MITIGATING RANSOMWARE RISK: DETERMINING OPTIMAL STRATEGIES FOR BUSINESSES, assesses the threats posed by ransomware, reviews trends in ransom demands and payments, highlights the effectiveness of controls, and ranks the most pervasive ransomware in terms of both frequency and severity.

"Leveraging Kivu's evidence-based data set from +8 years of experience, this research partnership with CCRS is designed to quantify the value of specific cybersecurity defenses and connect it with the company's bottom line," said Winston Krone, Co-Founder and Chief Research Officer at Kivu.

"Incident responders like Kivu play a critical role in attack management and ransom negotiation and thus have access to a rich dataset. This is the first study analyzing real-world event data which will better inform a more strategic approach to cybersecurity risk management," said Jen Copic, Senior Risk Researcher, Centre for Risk Studies.

 \*Key takeaways:

*   The global dataset provides an aggregate, real-world view of 422 attacks carried out on 416 organisations.
*   Industrials is the most impacted sector in the dataset, driven by a large number of events targeting capital goods manufacturing firms and professional services firms.
*   84% of the ransom events occurred in the Americas.
*   A ransom was paid 72% of the time as observed in this dataset.
*   94% of the ransomware variants accept negotiation on their pricing.

To download the paper and sign up for upcoming webinars, please visit:  https://kivuconsulting.com/mitigating-ransomware-risk/

About CCRS:

*   The Cambridge Centre for Risk Studies is based within the University of Cambridge Judge Business School. The Centre works closely with business partners in tackling complex issues of management science in risk.

About Kivu:

Kivu is a leading global cybersecurity firm that offers a full suite of cybersecurity services, including forensic investigation of, and recovery from, all forms of cyberattacks, continuous monitoring/detection/blocking of cyber threats, and strategy/compliance and testing. Kivu is an approved and trusted cybersecurity partner by 60+ insurance carriers and delivers its services to organizations in all industries. 

SOURCE Kivu Consulting

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Cambridge Centre for Risk Studies and Kivu Release Benchmark of Cost-Effective Responses to Cybercrime

CISA gives agencies deadline to patch against Google Chrome bug being actively exploited in the wild.

Although details about its real-world impact are vague, the Cybersecurity and Infrastructure Security Agency (CISA) added a Google Chrome flaw to its list of Known Exploited Vulnerabilities Catalog.

Google has already released a fixed version of Chrome browser for Windows, Mac, and Linux users. CISA has given government agencies until Dec. 26 to get a patch in place.

Tracked under CVE-2022-4262, CISA described the Google Chrome V8 Engine flaw as a "type confusion vulnerability." Attackers can exploit this kind of vulnerability by using a specially crafted HTML page to corrupt the heap and crashing the browser. Attackers can also exploit type confusion flaws to execute arbitrary code. An exploit for CVE-2022-4262 already exists in the wild, according to Google.

"Specific impacts from exploitation are not available at this time," CISA added.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Google Chrome Flaw Added to CISA Patch List

Microsoft warns that the Kremlin is ramping up cyberattacks against infrastructure and supply chains and starting disinformation campaigns as Russian troops lose on the battlefield.

With a beleaguered and retreating Russian military, analysts warn that winter's chill will be accompanied by a new barrage of cyberattacks against Ukraine's infrastructure, supply chains, partners, and political support across Europe and beyond.

Microsoft's Digital Threat Analysis Center predicts a significant increase in Russian cyberattacks over the coming months, as well as an expansion of existing campaigns like Prestige ransomware and wiper attacks on energy, water, and other vital infrastructure.

The Kremlin is also likely to push disinformation across social media across Europe with the intent of weakening public resolve to withstand skyrocketing energy costs and provide support for Ukraine's military.

It's time for organizations and security teams to prepare defenses against what Microsoft described as "multidimensional threats" from Russia.

"Ukraine has fought a brave defense both online and on-the-ground against a merciless Russian assault," the Microsoft report on Russian cyberattacks said. "With the help of its partner nations, companies and democratic citizens, we all can ensure that Ukraine and Europe's infrastructure is protected and democracy resilient in the face of authoritarianism this winter."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Source

DARKReading