If you haven't properly addressed the issue, you're already behind. But even if you've had a false start, it's never too late to get back up.

The digital world is ever-increasing in complexity and interconnectedness, and that's nowhere more apparent than in software supply chains. Our ability to build upon other software components means we innovate faster and build better products and services for everyone. But our dependence on third-party software and open source increases the complexity of how we must defend digital infrastructure.

Our recent survey of cybersecurity professionals found one-third of respondents monitor less than 75% of their attack surface, and almost 20% believe that over half of their attack surface is unknown or not observable. Log4Shell, Kaseya, and SolarWinds exposed how these statistics can manifest as devastating breaches with wide-reaching consequences. Cybercriminals already know supply chains are highly vulnerable to exploitation.

**Why Insecure Software Supply Chains Are Everyone's Problem**

Last year, a threat actor exploited a vulnerability in Virtual System Administrator (VSA) provider Kaseya to inject REvil ransomware into code for VSA. Kaseya supported thousands of managed service providers (MSPs) and enterprises, and its breach compromised a critical network within thousands of organizations. Consequently, these organizations' internal systems were also compromised.

The ripple effect that Kaseya had on its customers can happen to any organization that uses a third-party software vendor. The European Union Agency for Cybersecurity (ENISA) analyzed 24 recent software supply chain attacks and concluded that strong security protection is no longer enough. The report found supply chain attacks increased in number and sophistication in 2020, continued in 2021, and, based on recent attacks by Lapsus$, is likely to carry over through 2022.

Similar to third-party software vendors but at an even-greater magnitude, open source code has a devastating impact on digital function if left insecure — the havoc wreaked by Log4Shell illustrates this. These consequences are partly because open source software remains foundational to nearly all modern digital infrastructure and every software supply chain. The average application uses more than 500 open source components. Yet limited resources, training, and time available for the maintainers who voluntarily support projects mean they struggle to remediate the vulnerabilities. These factors have likely contributed to high-risk open source vulnerabilities remaining in code for years.

This issue demands immediate action. That's why the National Institute of Standards and Technology (NIST) released its security guidelines in February. But why are we still so slow to try and secure the software supply chain effectively? Because it's tough to know where to start. It's challenging to keep up with security updates for your own software and new products, let alone police other vendors to ensure they match your organization's standards. To add more complexity, many of the open source components that underpin digital infrastructure lack the proper resources for project maintainers to keep these components fully secure.

**Get Started**

So, how do we secure it? It all looks pretty daunting, but here's where you can start.

First, get your house in order and identify your attack resistance gap — the space between what organizations can defend and what they need to defend. Know your supply chain and implement strategies that set teams up for success:

*   **Require a software bill of materials (SBOM)** and maintain an accurate inventory of your organization's software licenses to know what vendors, programs, and networks could put you at risk. Open source software components are especially challenging to document; the Linux Foundation and International Organization for Standardization (ISO) have resources to help organizations determine an approach to track and identify open source for their SBOMs.

*   **Get a clear understanding of how your software (current or future purchases) supports or otherwise relates to your critical processes.** Knowledge of this relationship empowers security teams to make the business case for prioritizing security and better understand what elements of the business will be put at risk depending upon the vulnerable vendor or component.

*   **Shift ownership of software security to the earliest stages of development**.**** Known as "shifting left," this makes developers aware of security standards, so security and development teams collaborate to build secure products and reduces the amount of patching insecure products already deployed.

Then, enforce your strategies and standards to maintain security for your organization and the collective security of the Internet:

*   **Evaluate every software vendor based on incident readiness** and establish accountability. Including a vendor in your supply chain is an expression of trust, and you should only extend this trust when you believe that partner is worthy. Transparency across your organization and supply chain is key to excellent incident response. You can also use language from successful pre-existing programs for incident response and disclosure to inform guidelines.

*   **Adopt a clear integrity framework** and a detailed vendor onboarding process. The framework should include documentation of how each supplier's software license supports your organization and the security tools they leverage internally.

*   **Develop a strategy to improve the security** **of open source components** and contribute to their security through organizations dedicated to supporting project maintenance. Contributing to open source projects reduces the risk to your organization and everyone who uses open source code.

Most in the cybersecurity community are familiar with Murphy's Law: "Everything that can go wrong, will" — it defines the mindset of anyone working in this field. And if my experience in this industry has taught me anything, you just have to do your best to keep up with the inevitable increase in challenges, risks, and complexity of securing digital assets. Part of staying ahead of these challenges is remaining highly proactive when it comes to your security best practices, and if you haven't properly secured your software supply chain yet, you're already behind. But even if you've had a false start, the good news is that it's never too late to get back up.

It's a Race to Secure the Software Supply Chain — Have You Already Stumbled?

Most of those surveyed are concerned about AI-based attacks and deepfakes, but suggest that their organization is ready.

Almost all IT professionals believe that threat intelligence services and feeds will help their company get ready for and repulse malware attacks. Only 6% somewhat disagree with that idea, while 94% agree (44% strongly agree and 50% somewhat agree) that such tools are useful. Zero percent strongly disagree.

That's just one of the takeaways from the June 1 report from Dark Reading, "The State of Malware Threats." Dark Reading surveyed 153 IT and security professionals across industries including healthcare, financial services, information technology, manufacturing, telecommunications, and retail. The report aims to sketch out the malware landscape, see how it's affecting companies, and discover what security teams are doing to fight it.

Threat intelligence services and threat intelligence feeds distribute information such as IP addresses and URLs associated with known threats. Potentially the most prominent is the US Federal Bureau of Investigation's InfraGard, but many private companies offer informational feeds for free alongside their paid offerings. Feeds are useful for incorporating into security information and event management (SIEM) and other tools to keep up-to-date on the latest threats. Threat intelligence services will incorporate the data for a client so that they can take action, with various levels of defensive activity from the service.

Other questions garnered similar levels of agreement among respondents. For example, 86% either strongly (38%) or somewhat (48%) agreed that they would see artificial intelligence-powered attacks in the next year; 13% somewhat disagreed, and 1% strongly disagreed. Concerns about malicious use of deepfakes was a little more split, with 79% agreeing (26% strongly, 53% somewhat) and 21% disagreeing (17% somewhat, 4% strongly).

Attitudes among respondents' colleagues generated more discordance. Considering the statement that discovering a new vulnerability would change their security team's plans for the week, 73% agreed (24% strongly, 48% somewhat), but 28% (23% somewhat, 5% strongly) disagreed. That disagreement could come down to confidence in their organization's plan for handling a crisis rather than its lack of urgency.

The only statement that garnered more disagreement than agreement was the idea that the organization is less concerned about malware than it was last year. Only 44% agreed with that (15% strongly agree, 29% somewhat agree), and 56% disagreed (39% somewhat, 17% strongly). Again, the people who agreed might just be expressing confidence in the new tools and techniques their organization put into place after a rough 2021. After all, the Verizon Data Breach Investigations Report (DBIR) 2022 found that 40% of data breaches were due to malware, so nobody can really be resting easy.

For more, download the full report.

Threat Intelligence Services Are Universally Valued by IT Staff

Security is wasting time and resources patching low or no risk bugs. In this post, we examine why security practitioners need to rethink vulnerability management.

Sometimes, too much information is a mixed blessing. Security teams use multiple vulnerability scanners in an attempt to cope with a significant rise in both attack surface diversity and software vulnerabilities.

But they soon find themselves overwhelmed with results, which leads to a growing backlog of bugs that need to be fixed. This backlog has multiple negative impacts. It slows the development process because the flaws take time to patch, and ignoring them leads to an excessive amount of tech debt.

Many teams are using outdated practices and limited data, which studies find do not lead to a reduction in risk to an organization's attack surface. In fact, a recent analysis from RAND Corporation found no notable reduction of breaches in organizations with mature vulnerability management programs.

There has to be a better way to handle vulnerability management. I propose a rethink on vulnerability management.

**Too Much Noise, Too Few Signals  
**The new way forward in vulnerability management requires changing the perception that vulnerability management is simply about scanning your software for threats. Why? Because the information scanners give you lack context for any meaningful next steps that reduce risk.

Rezilion's own runtime research analysis finds, on average, only 15% of discovered vulnerabilities are loaded into memory, which makes them exploitable. That means, on average, only 15% of flaws require priority patching — or patching at all. There is more value to be had from applying risk context. Security teams must be able to glean how those gaps could be exploited and the consequences that could occur if they are not addressed.

Most significantly, vulnerabilities must be prioritized based on their severity. But I am not talking about severity based on the common vulnerability scoring system (CVSS). With traditional approaches, security teams are often spinning their wheels scanning and then remediating vulnerabilities that may not pose a serious or immediate threat simply because the scoring system deems them to be critical.

This lack of understanding on criticality can also cause added friction between security and DevOps teams, which typically spar over the need for speed and business agility while maintaining security.

**Patch What Matters  
**Rezilion conducted an analysis of 20 of the most popular container images on DockerHub along with several base operating system images from the three major cloud providers: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). The idea was to assess how many vulnerabilities are not relevant and which ones pose a real risk.

The findings showed more than 4,347 known vulnerabilities. Of those, 75% of those rated as critical or high in severity did not load to memory and posed no risk. Of course, it would be time-consuming and nearly impossible to patch all of these at once. The takeaway is that organizations can use runtime analysis to prioritize remediation of vulnerabilities — and not be daunted by the growing backlog. A vulnerability in a package that isn't being loaded to memory can't be exploited by an attacker.

With this new approach, organizations can utilize their limited resources to remediate the vulnerabilities that _actually_ pose a real threat of exploitation and patch them accordingly. This level of knowledge and prioritization also saves development time and prevents time-to-market delays.

When a risk-based approach is implemented to prioritize vulnerability remediation, the work shifts to containing the threats that pose a significant threat. That in turn reduces overhead and the vulnerability backlog. It also shrinks the software attack surface, making it more manageable to apply patches appropriately.

**It's Time for a Change in Vulnerability Management**

It's time for a new vulnerability management strategy and it's appropriate to reiterate a few things to think about as you do. Instead of applying static, score-based, or manual policy-driven allow or block decisions, use more context and runtime visibility to make risk-based decisions that are continuous and adaptive.

We are advocating for a rethink in which security teams don't just prioritize vulnerability remediation by using CVSS severity scores alone. Instead, look to tools that allow you to concentrate on the vulnerabilities that pose the greatest risk to _your_ organization. Rezilion provides tools to see into your software environment and determine which vulnerabilities pose a risk and which do not require patching. Security teams should utilize real-time contextualized security controls to understand their true software attack surface. But in order to apply context, you need data that will help identify weak spots in order to refocus remediation efforts on the most critical risks. Otherwise, you're just wasting valuable time finding signals in the noise.

**About the Author**  

    

  
Liran Tancman, CEO and co-founder of Rezilion, is one of the founders of the Israeli cyber command and spent a decade in Israel's intelligence corps. In 2013, Liran co-founded CyActive, a company that built a technology capable of predicting how cyber threats could evolve and offer future-proof security. Liran served as CyActive's CEO and led it from its inception to its acquisition by PayPal in 2015. Following the acquisition, Liran headed PayPal's global Security Products Center responsible for developing cutting-edge technologies to secure PayPal's customers.

Why We're Getting Vulnerability Management Wrong

CISA tells organizations running VMware servers without Log4Shell mitigations to assume compromise.

Organizations with public-facing VMware Horizon and Unified Access Gateway (UAG) servers without appropriate Log4Shell mitigations have been under a barrage of attacks from a range of attackers, including state-sponsored advanced persistent threat (APT) actors.

In fact, a new Cybersecurity and Infrastructure Agency (CISA) alert tells organizations running servers without Log4Shell updates to just assume they've been compromised and proceed with threat hunting and incident response. CISA added that in one instance, APT attackers were able to breach a disaster recovery network, move laterally, and steal sensitive data.

"If potential compromise is detected, administrators should apply the incident response recommendations included in this CSA and report key findings to CISA," the warning, issued along with the US Coast Guard Cyber Command (CGCYBER), said.

CISA also provides a list of indicators of compromise (IOC) and extensive technical details for threat hunters.

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

APT Groups Swarming on VMware Servers with Log4Shell

A new study says 97% of open source vulnerabilities linked to software supply chain risks are not attackable — but is "attackability" the best method for prioritizing bugs?

With vulnerability-management workloads ballooning in the era of heightened software supply chain security risks, a study out today suggests that only about 3% of today’s flaws are actually reachable by attackers. The data implies that if application security (appsec) pros and developers work to focus on fixing and mitigating what's truly attackable, they could drastically reduce the strain on their teams.

The new study by ShiftLeft, the 2022 AppSec Progress Report, suggests that appsec and development teams can more effectively sift through vulnerabilities by focusing on the "attackable" ones. Data from the report shows that developers saw a 97% reduction in false-positive library upgrade tickets once they considered attackability when examining packages in use with critically rated vulnerabilities.

If true, this would be a welcome relief to many. Vulnerability management was already hard enough as is, but the added complication of third-party flaws — especially the scale of impact of these vulnerabilities rippling across numerous pieces of software — creates an even more daunting workload that can only be managed through effective prioritization. Security and developers can only get to so many vulnerabilities in so many applications within any given time period. They need to make sure the ones they fix or mitigate with compensating controls are the ones that count.

**What Does 'Attackability' Mean for Security Vulnerabilities?**

Making the determination of what's attackable comes by looking beyond the presence of open source dependencies with known vulnerabilities and examining how they're actually being used, says Manish Gupta, CEO of ShiftLeft.

"There are many tools out there that can easily find and report on these vulnerabilities. However, there is a lot of noise in these findings," Gupta says. "For example, they do not consider how the dependency is used in the application; they don't even consider whether the app even uses the dependency."

The idea of analyzing for attackability also involves assessing additional factors like whether the package that contains the CVE is loaded by the application, whether it is in use by the application, whether the package is in an attacker-controlled path, and whether it is reachable via data flows. In essence, it means taking a simplified threat modeling approach to open source vulnerabilities, with the goal of drastically cutting down on the fire drills.

CISOs have already become all too familiar with these drills. When a new high-profile supply chain vulnerability like Log4Shell or Spring4Shell hits the industry back channels, then blows up into the media headlines, their teams are called to pull long days and nights figuring out where these flaws impact their application portfolios, and even longer hours in applying fixes and mitigations to minimize risk exposures.

To that point: The report noted that 96% of vulnerable Log4J dependencies were not attackable.

**Software Dependencies to the Fore**

Reliance on open source dependencies — both first-hand and through third-party dependencies — is growing in modern development stacks.

"For any major application that uses a large number of dependencies, it is common to have new CVEs multiple times a month," says Gupta. "Multiply that by all the apps in the organization, one can imagine it is no easy task to keep up with all the upgrades."

While updating a package might be easy, he says the associated development work surrounding such a change can often be significant. Often a single library upgrade can precipitate a battery of new tests not just for security but for functionality and quality, and it potentially could require refactoring of code.

"Any organization serious about product quality won't ship a product without thorough testing," he explains. "Also library upgrades are not always fail-safe; there's no guarantee that new versions of open source libraries will be fully backward compatible. So, sometimes teams are also required to change how their app works before they upgrade a library."

**Is Attackability Determination Feasible?**

According to Mark Curphey, founder of OWASP and a longtime appsec advocate, seeking a prioritization model like this is nothing new. However, he says that picking the dimensions of analysis to determine what's risky or attackable can be more complicated in today's application environment than what ShiftLeft proposes.

"It's true and fair to say that the vast majority of vulnerable methods in open-source libraries can't be reached and therefore are not exploitable, but we are now in a world where open-source libraries are like elaborate shop fronts offering all sorts of goodies for developers to consume," Curphey tells Dark Reading. "As an industry, we recently learned from the Log4J saga that when an issue is something like a JNDI interface that few people actually used, there were still paths to exploitation, and so we all had to face the issue."

He's currently on a listening tour for his latest appsec startup, Crash Override, to ask what CSOs' biggest appsec problems are today, and almost all of them say prioritization is their No. 1 problem. He believes it may well be appsec's next big problem to solve.

"So the fundamental premise of the report makes total sense, but what we have also learned from interviews is that answering that question is very hard and more complex than 'am I using a particular bit of code,'" Curphey says. "It's things like business criticality, which includes how many users the system has, how much money flows through it, its public profile, what type of data it is processing, where it is physically located, and therefore what laws are applicable. It's technical things like how it is connected to other systems and what controls, monitoring, and alerts are in place, and the list goes on."

The other problematic thing about using "attackability" or "reachability" as a prioritization filter is understanding the underlying technical data that's being used to determine what is reachable by an attacker, says Stephen Magill, vice president of product innovation for Sonatype.

"Attackability and 'reachability' can be helpful ways of prioritizing vulnerabilities when the underlying vulnerability data is good. What is not helpful is relying on attackability or reachability as a means of compensating for bad vulnerability data," Magill says. "All too often, this is what we see the industry doing: Using inaccurate methods of identifying dependencies, coupling this with noisy data on which versions of which dependencies are vulnerable, and then using reachability-based prioritization to filter the long list of vulnerabilities that results down to something manageable."

In other words, an attackability prioritization is as only as good as the vulnerability data feeding into it, so it is caveat emptor for security teams to truly look into the hood as to how they source their vulnerability data.

"Does it only come from public feeds, or is it the result of in-depth research by a dedicated security team? Also investigate how dependencies are tracked," Magill says. "Are they just the declared dependencies in manifest files or does the tool support analysis of binary artifacts, archives, JARs, etc. These questions will help you determine the quality of the findings being prioritized. As they say 'garbage in, garbage out.'"

Finally, Magill says security leaders need to remember that many threats exist to software supply chains beyond the normal churn of bugs that are found incidentally within open source projects.

"The biggest threats to our software supply chains are malicious, purposeful attacks on open source," he says. "That is a much larger problem that we should be focused on, and completely unrelated to attackability."

Only 3% of Open Source Software Bugs Are Actually Attackable, Researchers Say

Continuous monitoring is key to keeping up with software-as-a-service changes, but that's not all you'll need to get better visibility into your SaaS security.

When the White House warned all businesses to be on high alert for cyberattacks earlier this year, it was a wake-up call for many. While these kinds of warnings are often directed at government agencies or even critical infrastructure companies, a blanket warning is unusual.

All organizations should take this warning as an opportunity to review and, if needed, improve their security. Software-as-a-service (SaaS) application security is often a blind spot, so give your SaaS ecosystem some extra attention. SaaS is ubiquitous, highly configurable, and continuously updated, leaving many organizations vulnerable if they aren't closely monitoring for security gaps and changes.

Continuous monitoring is key to keeping up with SaaS changes, but that's not all you'll need to get better visibility into your SaaS security. Follow these seven steps to implement improved security measures that will help minimize your risk of a breach:

**1\. Close critical configuration gaps.** Some 55% of companies have sensitive data exposed to the internet, and misconfiguration is often to blame. The configurability that makes SaaS apps so powerful is also a weakness if not closely monitored. Get better visibility into the configurations of your SaaS platforms, beginning with those that house the most sensitive data and have the largest number of users. Consult best practices from the Cloud Security Alliance and other experts and close those configuration gaps.

**2\. Disable legacy authentication methods and protocols.** The majority of compromising sign-in attempts come from legacy authentication, which does not support multifactor authentication (MFA). Even if you have an MFA policy enabled on your directory, a bad actor can authenticate using a legacy protocol and bypass MFA. The best way to protect your environment from malicious authentication requests made by legacy protocols is to block these attempts altogether.

**3\. Enforce higher security authentication requirements.** An account is 99.9% less likely to be compromised if you use MFA.

**4\. Analyze and monitor conditional access rules.** Attackers often make modifications to conditional access rules to open access permissions further or implement exception rules. Since these rules can be nested and complex, it's important to validate rules and enable continuous monitoring. Keep an eye out for any changes and IP block exceptions.

**5\. Assess third-party access.** Third-party integrations and applications are often installed with high-level permissions and can be conduits for horizontal privilege escalation to other SaaS systems. Verify that third-party access and applications have been reviewed, approved, and are actively in use. To lower your risk of a third-party compromise, grant permissions and data access to third-party apps following the principle of least privilege and withdraw access as soon as it's no longer needed.

**6\. Identify public and anonymous data access permissions.** Least privilege access offers you better protection as ransomware attacks proliferate and the tool sets to execute attacks are more broadly distributed. Data access modeling and third-party app analysis can help identify exposure points to the public internet, allowing you to better protect all datasets.

**7\. Monitor for anomalous user activity.** Watch for password spraying and excessive failures. Monitor for compromised accounts in threat intelligence feeds. The faster you can spot unusual activity, the faster and better you can respond and limit the damage.

SaaS applications run business-critical functions in many organizations, and SaaS security should be considered as critical as the security measures in place for other technologies. Continuously monitoring your SaaS ecosystem, addressing misconfigurations quickly, and keeping a close eye on third-party access to your systems can help keep your data safe and your business running smoothly.

7 Steps to Stronger SaaS Security

We have a tech innovation problem, not a staff retention (or recruitment) problem.

Over 47 million Americans voluntarily quit their jobs in 2021. This unprecedented mass workforce exit was dubbed the "Great Resignation." Spurred by the COVID-19 pandemic and the long-term trend of workers rethinking their relationships with the labor market, those who quit cited low pay, a lack of advancement opportunities, and feeling disrespected as their top reasons for leaving, according to Pew Research. 

The cybersecurity industry was not immune to this wave of disruption. Despite the fact that the US added more than 250,000 people to the cybersecurity workforce between 2020 and 2021, the need for cybersecurity professionals increased by 30% in that same time. The demand for workers in cybersecurity is growing, driven by unprecedented levels of cyberattacks on governments, Fortune 500 companies, local businesses, and everywhere in between. But the supply of cybersecurity expertise is coming up short.

The cybersecurity talent shortage clearly has real impact, but it may not be as tied to retention strategies or the Great Resignation as many people think. We have a shortage of staff because we are not using security staff efficiently. Better technology that leads to better utilization of the people we have can ease the problem.

**New Solutions, Stronger Workforce**

Weak cybersecurity leaves organizations vulnerable to breaches, data loss, and regulatory penalties. Organizations tap vendors for a robust array of cybersecurity technologies to alleviate these evolving issues. Vendors consume massive budgets to cultivate, hire, and retain an army of workers with the right innovative mindset and technical capabilities to create solutions that address sophisticated, next-generation cyber threats.

But cybersecurity vendors can't create those solutions because they're having trouble retaining enough people in the workforce, right? Well, not exactly.

The superficial reason for the workforce shortage is the booming labor market. In industries where low pay, few promotion opportunities, burnout, general work/life inflexibility, and poor job benefits are the reason workers are fleeing, there is an absolute need for comprehensive solutions to address those new-normal problems. For cybersecurity, however, the reality of the talent shortage is that technology isn't meeting the moment.

The talent pool may, in fact, be dwindling. But the technology platforms and solutions we have need to be better at making life easier — both for current talent and to enhance the capabilities of customers vulnerable to a host of attacks. Automation is key to meeting those goals.

What if cybersecurity vendors solved the issue and helped talented people out there right now by unlocking the ability to embrace true innovation? What if vendors make it easier for everyday users to operate products for effective cybersecurity? The tools themselves need to be simplified and reliable. If there were no need for an overly specialized and multitudinous amount of effort in the workforce, then there would be no technical debt.

Let's be clear: We're not suggesting taking away the expertise of cybersecurity professionals. This is about innovating enough to alleviate the complexities of the solutions and give every customer control during a threat situation. Adopting security automation is the core of cybersecurity democratization.

So what would that look like?

**Automation and Democratization**

It's on industry leaders to facilitate new tools for the everyday user. Think about it from the perspective of the type of tech that regular workers take for granted each day.

Google's G-Suite gives users easy, intuitive access to products like Docs and email; Wix helps users drag, drop, and easily create an entire personalized website; Canva turns anyone into a designer, not just people with hours of Photoshop experience; and so on. These were previously cumbersome processes and difficult-to-use sets of products before innovation tipped the balance toward everyday, intuitive use. This is what needs to be done for cybersecurity.

To be proficient, companies need to develop technology that's going to help empower the everyday user with tools and knowledge that give them understandable visibility into cyberattacks. Here are the elements such automated and democratized technology would need to cover.

*   **Detection:** By automating proactive threat detection and prevention capabilities, people can stay a step ahead of cybercriminals without the need for specialized security skills.
*   **Response:** Ideally when you identify a cyber alert, you need to know what to do with it. Normally the reaction is panic. Incident responses via automated tools need to tell users step by step what to do to mitigate the spread of the attack and improve their cyber resilience over time.
*   **Integration:** Security architectures may be unique, but new solutions must be open source enough to connect any tool in an existing security stack with additional out-of-the-box integrations as threats evolve.

The talent shortage will continue if we don't look at the problem in a different and radical way. Making advanced tools more accessible for all businesses and verticals will foster innovation and solve the talent shortage that is leaving business and consumer data vulnerable. Solutions should become as easily accessible as sending and receiving an email or swiping through your iPhone. The tools and ability to innovate are already here — they just need to be distributed.

The Cybersecurity Talent Shortage Is a Myth

Analysts say an 18% drop in ransomware attacks seen in May is likely fleeting, as Conti actors regroup.

A 18% drop in ransomware attacks in May is probably the result of Conti's shutdown, but the actors are regrouping under other brands, including KaraKurt, Black Byte, Hive, and Black Basta, analysts said. 

The latest report from NCC Group's threat intelligence team shows LockBit 2.0 maintained its top spot among ransomware groups, launching 40% of all attacks in May. Black Basta, which was discovered in April, along with Hive were behind 7% of attacks last month.   

“Conti’s possible shutdown represents a significant change for the ransomware threat landscape, and it cannot go ignored," said Matt Hull, global lead for strategic threat intelligence at NCC Group, in a statement announcing the ransomware attack report findings. "It will be interesting to see which smaller groups replace it as it rebrands, and how these new or evolved actors will behave – which NCC Group will of course continue to monitor.”

The findings also show industrial and critical infrastructure remain an attractive target. The sector was on the receiving end of 31% of attacks in May, followed by consumer cyclicals at 22% and technology at 12%. 

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

Without Conti on the Scene, LockBit 2.0 Leads Ransomware Attacks

Bronze Starlight’s use of multiple ransomware families and its victim-targeting suggest there’s more to the group’s activities than just financial gain, security vendor says.

A China-based advanced persistent threat (APT) actor, active since early 2021, appears to be using ransomware and double-extortion attacks as camouflage for systematic, government-sponsored cyberespionage and intellectual property theft.

In all of the attacks, the threat actor has used a malware loader called the HUI Loader — associated exclusively with China-backed groups — to load Cobalt Strike Beacon and then deploy ransomware on compromised hosts. Researchers at Secureworks who are tracking the group as “Bronze Starlight” say it’s a tactic they have not observed other threat actors use.

Secureworks also says it has identified organizations in multiple countries that the adversary appears to have compromised. The group’s US-based victims include a pharmaceutical company, a law firm, and a media company with offices in Hong Kong and China. Others include electronic component designers and manufacturers in Japan and Lithuania, a pharmaceutical company in Brazil, and the aerospace and defense division of an Indian conglomerate. Some three-quarters of Bronze Starlight’s victims so far are organizations that have typically been of interest to government-sponsored Chinese cyber-espionage groups.

**Cycling Through Ransomware Families**

Since it began operations in 2021, Bronze Starlight has used at least five different ransomware tools in its attacks: LockFile, AtomSilo, Rook, Night Sky, and Pandora. Secureworks’ analysis shows that the threat actor used a traditional ransomware model with LockFile, where it encrypted data on a victim network and demanded a ransom for the decryption key. But it switched to a double-extortion model with each of the other ransomware families. In these attacks Bronze Starlight attempted to extort victims by both encrypting their sensitive data and threatening to leak it publicly. Secureworks identified data belonging to at least 21 companies posted on leak sites associated with AtomSilo, Rook, Night Sky, and Pandora.

While Bronze Starlight appears on the surface to be financially motivated, its real mission appears to be cyberespionage and intellectual property theft in support of Chinese economic objectives, says Marc Burnard, senior consultant information security research at Secureworks. The US government last year formally accused China of using threat groups such as Bronze Starlight in state-sponsored cyber-espionage campaigns.

“The victimology, tooling, and rapid cycling through ransomware families suggest that Bronze Starlight’s intent may not be financial gain,” he says. Instead, it’s possible that the threat actor is using ransomware and double extortion as a cover to steal data from organizations of interest to China and destroy evidence of its activity.

Bronze Starlight has consistently targeted only a small number of victims over short periods of time with each ransomware family — something that threat groups don’t often do because of the overhead associated with developing and deploying new ransomware tools. In Bronze Starlight’s case, the threat actor appears to have employed the tactic to prevent drawing too much attention from security researchers, Secureworks said.

**The Chinese Connection**

Burnard says the threat actor’s use of the HUI Loader along with a relatively rare version of PlugX, a remote access Trojan linked exclusively to China-backed threat groups, is another sign that there’s more to Bronze Starlight than its ransomware activity might suggest.

“We believe the HUI Loader is a tool unique to Chinese state-sponsored threat groups,” Burnard says. It is not widely used, but where it has been used, the activity has been attributed to other likely Chinese threat group activity, such as one by a group dubbed Bronze Riverside that is focused on stealing IP from Japanese companies. 

“In terms of the use of the HUI Loader to load Cobalt Strike Beacons, this is one key characteristic of the Bronze Starlight activity that connects the broader campaign and five ransomware families together,” Burnard says.

Another sign that Bronze Starlight is more than just a ransomware operation involves a breach that Secureworks investigated earlier this year, where Bronze Starlight broke into a server at an organization that had previously already been compromised by another China-sponsored threat operation called Bronze University. In this incident, though, Bronze Starlight deployed the HUI Loader with Cobalt Strike Beacon on the compromised server, but it did not deploy any ransomware. 

“Again, this raises an interesting question around links between Bronze Starlight and state-sponsored threat groups in China,” Burnard says.

There’s also evidence that Bronze Starlight is learning from its intrusion activity and improving the HUI Loader’s capabilities, he adds. The version of the loader that the group used in its initial intrusions, for instance, were merely designed to load, decrypt, and execute a payload. But an updated version of the tool that Secureworks came across while responding to a January 2022 incident revealed several improvements. 

“The updated version comes with detection evasion techniques, such as disabling Windows Event Tracing for Windows \[ETW\] and Antimalware Scan Interface \[AMSI\] and Windows API hooking,” Burnard notes. “This indicates the HUI Loader is actively being developed and upgraded.”

Secureworks’ investigation shows that Bronze Starlight primarily compromises Internet-facing servers on victim organizations by exploiting known vulnerabilities. So as part of a multilayered approach to network security, network defenders should ensure that Internet-facing servers are patched in a timely manner, Burnard says. 

“While the focus is often on zero-day exploitation, we often see threat groups like Bronze Starlight exploit vulnerabilities that already have a patch available," he says.

Chinese APT Group Likely Using Ransomware Attacks as Cover for IP Theft

Johnson Controls will roll out the Tempered Networks platform across deployments of its OpenBlue AI-enabled platform.

**CORK, Ireland, June 23, 2022 —** Johnson Controls (NYSE: JCI), the global leader for smart, healthy, and sustainable buildings, today acquired zero trust cybersecurity provider – Tempered Networks, based in Seattle, Washington. Tempered Networks has created ‘Airwall’ technology, an advanced self-defense system for buildings that enables secure network access across diverse groups of endpoint devices, edge gateways, cloud platforms and service technicians. It represents a step-change in operational technology built on secure transmission pipelines to ensure buildings data exchanges and service actions can only take place between people and devices that are continuously authenticated.

The acquisition gives Johnson Controls the capability to provide zero trust security within the fabric of its OpenBlue secure communications stack, advancing its vision of enabling fully autonomous buildings that are inherently resilient to cyberattack.

**_How Airwall Works_**

Tempered Networks Airwall technology uses the Host Identity Protocol and a cloud-based policy orchestration platform to create new overlay networks built on encrypted and authenticated communication. The policy manager (a.k.a. the conductor) enforces configured digital policies that control connections within the cloaked overlay system. The default position for the policy manager is ‘zero trust’, i.e., only allowing connections between continuously authenticated and authorized entities. Once a communicating device authenticates itself correctly, an encrypted tunnel is created through which data flows. The advantages of this cybersecurity technique are as follows:

1\. The creation of an always-on and software-defined security perimeter protecting device-to-device, device-to-cloud and device-to-user interactions.

2\. Airwall achieves this by using Host Identity Protocol to create a cloaked and micro-segmented network which overlays a building’s existing network infrastructure, making the solution also highly cost-effective.

3\. A new level of authentication for connected building systems is created, allowing for greater system automation of functions such as heating and cooling, lighting, security and airflows.

“When it comes to buildings, we must create easily implementable cybersecurity defenses as we’re often dealing with critical infrastructure, including assets such as data centers and hospitals,” said Vijay Sankaran, vice president and chief technology officer, Johnson Controls. “Tempered Networks Airwall approach is purpose-built for our sector as it’s designed around principles of zero trust, securing device communications as data moves between devices and the cloud – so enabling remote building optimization in the most trusted way possible.”

**_Technology Integration_**

Tempered Networks Airwall technology is being integrated into Johnson Controls OpenBlue platform which is increasingly recognized as a leading smart building software platform with advanced AI-enabled building management capabilities\[1\]. OpenBlue provides a flexible computing approach for converging building technologies and making those technologies more insightful, powerful, and optimized through edge AI and through full machine learning in the cloud. The ultimate goal is to make all buildings smarter, healthier and more sustainable.

Financial terms of the transaction were not disclosed.

To learn more about Johnson Controls' approach to cybersecurity, please visit www.johnsoncontrols.com/cybersolutions.

See an explanation video for Tempered Networks Airwall technology here.

Source

DARKReading