Amazon Security Lake will allow organizations to create a purpose-built, standards-based data lake to aggregate and store security data.

Amazon Web Services unveiled the Amazon Security Lake, a standards-based data lake for security data, at this week's AWS re:Invent 2022 conference. The new cybersecurity service will allow organizations to aggregate logs and event data from multiple sources and analyze them to quickly detect and respond to threats.

Security data is usually scattered across an organization's environment, as applications, firewalls, and identity providers maintain their own logs and event data. They are also often in disparate data formats, making it difficult for security teams to aggregate them. Creating processes to normalize data across multiple sources can be costly and time-consuming to build, and managing the data lifecycle is complex.

Many organizations are turning to security data lakes to manage security data from multiple data sources and to integrate with other security tools. These data lakes help centralize and store unlimited amounts of data to power investigations, analytics, threat detection, and compliance initiatives. It also makes it possible to combine the organization's own data with enriched data from other sources for deeper context.

With Amazon Security Lake, organizations will be able to store, analyze, and understand the data collected from both cloud and on-premises infrastructure, the company said. Because Amazon Security Lake supports the Open Cybersecurity Schema Framework (OCSF), an open specification for security telemetry data, it can ingest data from a number of third-party providers. Having the data available in OCSF format means security teams can use the analytics tool of their choice to uncover malicious activity.

“After customers choose their data sources, Amazon Security Lake automatically aggregates and normalizes data from AWS, combines it with third-party sources that support OCSF (an open standard), and optimizes it into a format that is easy to store and query,” AWS said in a statement.   

Amazon Security Lake aggregates data from AWS services, such as CloudTrail, Lambda, AWS Security Hub, GuardDuty, and AWS Firewall Manager, as well as from firewalls and endpoint security products from other companies. Several dozen companies have announced integrations with Amazon Security Lake, including Cisco, CrowdStrike, Palo Alto Networks, Barracuda, Lacework, Trend Micro, and Laminar. Security teams can analyze the data using Amazon's own security services such as Amazon Athena, Amazon OpenSearch, and Amazon SageMaker, as well as third-party providers such as IBM, Splunk, Sumo Logic, Securonix, and SentinelOne.

The data lakes are built using Amazon Simple Storage Service (S3) and AWS Lake Formation, the company said.

AWS Unveils Amazon Security Lake at re:Invent 2022

The threat actor behind an August intrusion used data from that incident to access customer data stored with a third-party cloud service provider, and affiliate GoTo reports breach of development environment.

An attacker who breached the software development environment at LastPass this August and stole source code and other proprietary data from the company appears to have struck the password management firm again.

On Wednesday, LastPass disclosed it is investigating a recent incident where someone using information obtained during the August intrusion managed to access source code and unspecified customer data stored within an unnamed third-party cloud storage service. LastPass did not disclose what kind of customer data the attacker might have accessed but maintained that its products and services remained fully functional.

**Unusual Activity**

"We recently detected unusual activity within a third-party cloud storage service, which is currently shared by both LastPass and its affiliate, GoTo," LastPass said. "We immediately launched an investigation, engaged Mandiant, a leading security firm, and alerted law enforcement."

LastPass' statement coincided with one from GoTo, also on Wednesday, that referred to what appeared to be the same unusual activity within the third-party cloud storage-service. In addition, GoTo's statement described the activity as impacting its development environment but offered no other details. Like LastPass, GoTo said its videoconferencing and collaboration services remained fully functional while it investigates the incident.

It is unclear if the apparent breach of GoTo's development environment is related in any way to the August intrusion at LastPass or if the two incidents are entirely separate. Both companies declined to answer a Dark Reading question on whether the two incidents might be related.

The new breach at LastPass suggests that attackers may have accessed more data from the company in August than previously thought. LastPass has previously noted the intruder in the August breach gained access to its development environment by stealing the credentials of a software developer and impersonating that individual. The company has maintained since then that the threat actor did not gain access to any customer data or encrypted password vaults because of the design of its system and the controls it has in place.

**Were LastPass' Security Controls Strong Enough?**

Those controls include a complete physical and network separation of the development environment from the production environment and ensuring the development environment contains no customer data or encrypted vaults. LastPass has also noted that it does not have any access to the master passwords to customer vaults, thereby ensuring that only the customer can access it.

Michael White, technical director and principal architect at Synopsys Software Integrity Group, says LastPass' practice of separating dev and test and making sure that no customer data is used in dev/test are certainly good practices and in line with recommendations.

However, the fact that a threat actor managed to gain access to its development environment means they potentially had the ability to do a lot of damage.

"The short answer is that we simply cannot know based on what has been said publicly," White says. "However, if the impacted dev systems have any access to common internal tools used for software build and release — for example, source code repositories, build systems, or binary artifact storage — it could allow an attack to insert a surreptitious back door into the code."

So, the mere fact that LastPass might have separated development and test from its production environment is not enough guarantee that customers were fully protected, he says.

LastPass itself has only confirmed the threat actor behind the August breach as accessing its source code and some other intellectual property. But it's unclear if the actor might have done other damage as well, researchers tell Dark Reading.

Joshua Crumbaugh, CEO at PhishFirewall, says development environments tend to present easy targets for threat actors to inject malicious code without being detected. "That malicious code is like finding a needle that you don't know to look for in a haystack of needles," he says.

Development environments are also known for having hardcoded credentials and for insecure storage of API keys, user credentials, and other sensitive information. "Our research continuously demonstrates that development teams are one of the least security aware departments at most organizations," Crumbaugh says. He adds that LastPass' breach sequel suggests they didn't completely trace the attackers' actions after the first breach.

LastPass Discloses Second Breach in Three Months

A vulnerability discovered in GitHub Actions could allow an attacker to poison a developer's pipeline, highlighting the risk that insecure software pipelines pose.

An attacker submitting changes to an open source repository on GitHub could cause downstream software projects that include the latest version of a component to compile updates with malicious code.

That's according to software supply chain security firm Legit Security, which said in an advisory published on Dec. 1 that this "artifact poisoning" weakness could affect software projects that use GitHub Actions — a service for automating development pipelines — by triggering the build process when a change is detected in a software dependency. 

The vulnerability is not theoretical: Legit Security simulated an attack on the project that manages Rust, causing the project to recompile using a customized — and malicious — version of the popular GCC software library, the company stated in the advisory.

The problem likely affects a large number of open source projects because maintainers typically will run tests on contributed code before they actually analyze the code themselves, says Liav Caspi, chief technology officer of Legit Security.

"It is a common pattern today," he says. "A lot of open source projects today, upon a change request, they run a bunch of tests to validate the request because the maintainer does not want to have to review the code first. Instead, it automatically run tests."

The attack takes advantage of the automated build process through GitHub Actions. In the case of the Rust programming language, the vulnerable pattern could have allowed an attacker to execute code in a privileged way as part of the development pipeline, stealing repository secrets and potentially tampering with code, Legit Security said.

"To put it simply: in a vulnerable workflow, any GitHub user can create a fork that builds an artifact," the company stated in its advisory. "Then inject this artifact into the original repository build process and modify its output. This is another form of a software supply chain attack, where the build output is modified by an attacker."

The vulnerability enables an attack similar to the malware-insertion attack that targeted CodeCov and, through that company's software, its downstream customers.

"\[T\]he lack of native GitHub implementation for cross-workflow artifacts communication led many projects and the GitHub Actions community to develop insecure solutions for cross-workflow communication and made this threat highly prevalent," Legit Security stated in the advisory.

GitHub confirmed the issue and paid a bounty for the information, while Rust fixed its vulnerable pipeline, Legit Security stated.

    

Source: Legit Security

**Software Supply Chain Needs Security**

The vulnerability is the latest security issue to affect software supply chains. Industry and government agencies have increasingly sought to bolster the security of open source software and software provided as a service.

In May 2021, for example, the Biden administration released its executive order on Improving the Nation's Cybersecurity, a federal rule that, among other requirements, mandates that the government will require baseline security standards for any software its purchases. On the private industry side, Google and Microsoft have pledged billions of dollars to shore up security in the open source ecosystem, which provides the code that comprises more than three-quarters of the average application's codebase.

**Logical, But Vulnerable**

The security issue belongs to a hard-to-find class of problems known as logic issues, which include issues with permissions, the potential for forked repositories to be inserted into a pipeline, and a lack of differentiation between forked and base repositories.

Because software projects often use automated scripts to check code submissions before forwarded them to the maintainers, pull requests will be run through automation before any human checks them for malicious code. While the automation saves time, it also should be considered a way for attackers to insert malicious code into the pipeline.

"When you are doing open source development, the problem is bigger, because you are accepting contribution from anyone in the world," Caspi says. "You are executing things that you cannot trust."

GitHub acknowledged the issue and expanded the ways of excluding submissions from outside collaborators from being automatically inserted into the Actions pipeline. The company updated its GetArtifact and ListArtifacts APIs with the goal of providing more information to help determine whether an artifact can be trusted.

"Anyone that does anything like the Rust project did — trusting the input from a third party — then they are still vulnerable," Caspi says. "It is a logic problem. GitHub just made it easier to write a safer script."

Artifact Poisoning in GitHub Actions Imports Malware via Software Pipelines

Though there have been fewer than expected publicly reported attacks involving the vulnerability, nearly three-quarters of organizations remain exposed to it.

The Log4j vulnerability continues to present a major threat to enterprise organizations one year after the Apache Software Foundation disclosed it last November — even though the number of publicly disclosed attacks targeting the flaw itself has been less than many might have initially expected.

A high percentage of systems still remain unpatched against the flaw, and organizations face challenges in finding and remediating the issue and then preventing the flaw from being reintroduced into the environment, security researchers say.

"The fact that Log4j is used in \[nearly\] 64% of Java applications and only 50% of those have updated to a fully fixed version means attackers will continue to target it," says David Lindner, CISO at Contrast Security. "At least for now, attackers continue to have a field day in finding paths to exploit through Log4j."

**Multiple Attacks But Fewer Than Expected**

The Log4j flaw (CVE-2021-44228), commonly referred to as Log4Shell, exists in Log4j's Java Naming and Directory Interface (JNDI) function for data storage and retrieval. It gives remote attackers a trivially easy way to take control of vulnerable systems — a problem given that Log4J is used in virtually every Java application environment. Security researchers consider it as one of the most significant vulnerabilities in recent years because of its prevalence and the relative ease with which attackers can exploit it.

Over the past year, there have been numerous reports about threat actors targeting the flaw as a way to gain initial access into a target network. Many of these attacks have involved nation-state-backed advanced persistent threat (APT) groups from China, North Korea, Iran, and other countries. In November, for instance, the US Cybersecurity and Infrastructure Security Agency (CISA) warned about an Iran-government-backed APT group exploiting the Log4j vulnerability in an unpatched VMware Horizon server to deploy cryptomining software and credential harvesters on a federal network.

The warning was similar to one from Fortinet in March about Chinese threat actor Deep Panda using the identical vector to deploy a backdoor on target systems and another from Ahn Labs about North Korea's Lazarus Group distributing its own backdoor the same way. Others such as Microsoft have also reported observing state actors such as Iran's Phosphorous group and China's Hafnium threat actor using Log4 to drop reverse shells on infected systems.

Despite such reports — and several others about financially motivated cybercrime groups targeting Log4j — the actual number of publicly reported compromises involving Log4 has remained comparatively low, especially when compared to incidents involving Exchange Server vulnerabilities like ProxyLogon and ProxyShell. Bob Huber, chief security officer at Tenable, says the scale and scope of reported attacks have been surprisingly lower than expected, considering the simplicity of the vulnerability and the attack path. "Only recently have we seen some significant evidence of targeting, as noted by recent nation state activity from CISA," Huber says.

**Undiminished Threat**

However, that does not mean the threat from Log4j has diminished over the past year, security researchers note.

For one thing, a large percentage of organizations remain as vulnerable to the threat as they were a year ago. An analysis of telemetry related to the bug that Tenable recently conducted showed 72% of organizations were vulnerable to Log4j, as of Oct. 1. Tenable found that 28% of organizations globally have fully remediated against the bug. But Tenable found that organizations which had remediated their systems often encountered Log4j again and again as they added new assets to their environments.

In many instances — 29%, in fact — servers, Web applications, containers, and other assets became vulnerable to Log4j soon after initial remediation.

"Assuming organizations build the fix into the left side of the equation — during the build pipeline for software — rates of reintroduction should diminish," Huber says. "Much of the rate of reintroduction and change depends greatly on an organization's software release cycle."

Also, despite almost ubiquitous awareness of the flaw within the cybersecurity community, vulnerable versions of Log4j remain vexingly hard to find at many organizations because of how applications use it. Some applications might use the open source logging component as a direct dependency in their applications, and in other instances an application might use Log4j as a transitive dependency — or a dependency of another dependency, says Brian Fox, CTO at Sonatype.

"Since transitive dependencies are introduced from your direct dependency choices, they may not always be known or directly visible to your developers," Fox says.

In many cases, when the Apache Foundation first disclosed Log4Shell, companies had to send out thousands of internal emails, collect results in spreadsheets, and recursively scan file systems, Fox says. "This cost companies valuable time and resources to patch the component and prolonged the magnitude of the vulnerability's malicious effect," he says.

Data from the Maven Central Java repository that Sonatype maintains shows that 35% of Log4 downloads currently continue to be of vulnerable versions of the software. "Many companies are still trying to build their software inventory before they can even begin a response and are unaware of the implications of transitive dependencies," Fox says.

Because of all of the issues, the US Department of Homeland Security review board earlier this year concluded that Log4 is an endemic security risk that organizations will need to contend with for years. Members of the board assessed that vulnerable instances of Log4j will remain in systems for many years to come and put organizations at risk of attack for the foreseeable future.

**The One Positive Outcome**

Security researchers tracking the bug say that the positive fallout from Log4j is the heightened attention it has drawn to practices such as software composition analysis and software bill of materials (SBOM). The challenges that organizations have faced just determining whether they are vulnerable or where the vulnerability might exist in their environment has fostered a better understanding of the need for visibility into all the components in their codebase — especially those from open source and third-party sources.

"The investigation into the Log4J issue has reaffirmed the need for better software supply chain attestation in addition to SBOMs that keep up with the speed of DevOps," says Matthew Rose, CISO at ReversingLabs. "Application security and architecture teams have realized that just looking for risk in parts of the application like source code, APIs, or open source packages is not enough. They now realize that a complete understanding of the application's architecture is just as important as finding SQLI or cross-site scripting bugs (XSS)," he says.

One Year After Log4Shell, Most Firms Are Still Exposed to Attack

The Hell's Keychain attack vector highlights common cloud misconfigurations and secrets exposure that can pose grave risk to enterprise customers.

A vulnerability in IBM Cloud databases for PostgreSQL could have allowed attackers to launch a supply chain attack on cloud customers by breaching internal IBM Cloud services and disrupting the hosted system's internal image-building process.

Security researchers from Wiz discovered the flaw, which they dubbed "Hell's Keychain." It included a chain of three exposed secrets paired with overly permissive network access to internal build servers, the researchers revealed in a blog post published Dec. 1. 

While now patched, the vulnerability is significant in that it represents a rare supply-chain attack vector impacting the infrastructure of a cloud service provider (CSP), Wiz CTO Ami Luttwak tells Dark Reading. The discovery also uncovers a class of PostgreSQL vulnerabilities affecting most cloud vendors, including Microsoft Azure and Google Cloud Platform.

"This is a first-of-a-kind supply-chain attack vector, showing how attackers might be able to leverage mistakes in the build process to take over the entire cloud environment," he says.

Specifically, researchers uncovered "major risk caused by improper sanitation of build secrets from container images, allowing for an attacker to gain write access to the central container image repository," Luttwak says. This would have allowed the actor to run malicious code in customers’ environments and modify the data stored in the database.

"Modifications to the PostgreSQL engine effectively introduced new vulnerabilities to the service," the researchers wrote in their post. "These vulnerabilities could have been exploited by a malicious actor as part of an extensive exploit chain culminating in a supply-chain attack on the platform."

As mentioned, the ability to use PostgreSQL to breach IBM Cloud is not unique to the service provider, researchers said. Wiz already has found similar vulnerabilities in other CSP environments, which they plan to disclose soon and which highlight a broader issue of cloud misconfigurations that pose a supply chain threat to enterprise customers.

The existence of the flaw also highlights how improper management of secrets — or long-lived authentication tokens for cloud APIs or other enterprise systems — can impose a high risk of unwanted intrusion by attackers on an organization using a cloud provider, Luttwak says.

"Finding and utilizing exposed secrets is the No. 1 method for lateral movement in cloud environments," he says.

For now, the researchers said they worked with IBM to remedy the issue in IBM Cloud and no customer mitigation action is required.

**Uncovering the Chain**

Researchers were doing a typical audit of IBM Cloud's PostgreSQL-as-a-service to find out if they could escalate privileges to become a "superuser," which would allow them to execute arbitrary code on the underlying virtual machine and continue challenging internal security boundaries from there.

Based on their experience, they said the ability to carry out a supply chain attack on a CSP lies in two key factors: the forbidden link and the keychain.

"The forbidden link represents network access — specifically, it is the link between a production environment and its build environment," the researchers wrote. "The keychain, on the other hand, symbolizes the collection of one or more scattered secrets the attacker finds throughout the target environment."

On its own, either scenario is "unhygienic," but not critically dangerous. However, "they form a fatal compound when combined," the researchers said.

Hell’s Keychain held three specific secrets: a Kubernetes service account token, a private container registry password, and continuous integration and delivery (CI/CD) server credentials.

Combining this chain with the so-called forbidden link between Wiz's personal PostgreSQL instance and IBM Cloud databases’ build environment allowed researchers to enter IBM Cloud’s internal build servers and manipulate their artifacts, the researchers said.

**Implications for Cloud Security**

The scenario presented in Hell's Keychain represents a broader problem within the cloud security community that demands attention and remediation, the researchers said. To wit: scattered plaintext credentials that are found across cloud environments that impose a huge risk on an organization, impairing service integrity and tenant isolation, they said.

For this reason, secret scanning at all stages of the pipeline is crucial, including in CI/CD, code repo, container registries, and within the cloud, Luttwak says.

"Furthermore, lockdown of privileged credentials to the container registry is crucial, as these credentials are often overlooked but are actually the keys to the kingdom," he adds.

CSP customers also should consider image signing verification via admission controllers to ensure these sort of attacks are prevented entirely, Luttwak says.

Hell's Keychain also highlights a common misconfiguration in the use of the popular Kubernetes API for container management within the cloud — pod access, ''which can lead to unrestricted container registry exposure," he says.

Another best practice the researchers recommend is any organization — CSP or otherwise — deploying a cloud environment can take is to impose strict network controls between the Internet-facing environment and the organization's internal network in the production environment, so attackers can't gain a deeper foothold and maintain persistence if they do manage to breach it.

IBM Cloud Supply Chain Vulnerability Showcases New Threat Class

As consumers catch on to the dangers, protection could become a major topic for legislative bodies.

It's no longer a case of _if_ but _when_ a data breach will occur — and consumers are catching on. In the age of digital services, this is a critical development because it means the average US consumer is now demanding the power to make more informed decisions about the way their data is used, stored, and processed. And for US legislative bodies, it means data protection could soon be a major topic on the ballot.

According to the latest Thales Consumer Digital Trust Index, almost half (48%) of US consumers report being victims of a data breach — higher than their global counterparts, at 33%. The sheer volume of cyberattacks in the US has brought data security to the mainstream eye, and consumers are tuning into the legal fallout from breaches affecting millions, including T-Mobile's 2021 cyberattack and Drizly's 2020 hack. Now, they are starting to make more informed decisions about how they want their data handled going forward.

**The Public Is Taking Data Security into Their Own Hands**

Breaches and ransomware attacks have dominated headlines and news cycles, and one in 20 victims reported first hearing about a breach affecting them on the news. Eleven percent of those companies took up to six months to inform consumers about a data breach — a failure on the part of the companies in question.

This pattern of weak transparency has driven consumers to take security matters into their own hands, as they realize inaction is not an option. Just over a fifth have stopped using a company that suffered a data breach, with a large portion of those requesting the company delete their information altogether, while others are keeping a closer eye on their accounts for suspicious activity (21%).

These actions show that data security is a priority for consumers, and it's good practice for organizations to enable them to share this responsibility, in part. Allowing for extra security measures on digital accounts, such as two-factor authentication (2FA), gives consumers more of a sense of control over their information — and that peace of mind is a key element in building trust.

**Paying a Fine Is Not Enough**

As for what they expect from companies that fail to keep their data secure, financial compensation is a natural consequence. Of surveyed consumers, 53% believe companies should offer compensation to victims, but, when it comes to overseeing regulations, only 31% believe companies should receive large fines for breaches, meaning it is far from the biggest priority from a consumer perspective. What more consumers want is better data security measures — not big payouts.

However, the methods consumers believe should be used differ. More than half believe companies should be forced into mandatory data protection controls following a breach. This includes encryption and 2FA, which have long been favored options. And just under half believe companies should be subject to more stringent regulation — for example, being monitored for 12 to 14 months post-breach. Others believe companies should be required to employ more cyber specialists — but the reigning feeling is that regulatory oversight would be a major improvement.

**We're Looking to the Future of US Data Privacy and Security**

One possible contender for that oversight is the American Data Privacy and Protection Act (ADPPA). Similar to the European Union's General Data Protection Regulation (GDPR), which put in place necessary guidelines for European consumer data, ADPPA is a landmark US federal privacy proposal that could potentially meet sweeping demands for security and privacy. Proposed in July 2022, it could also face a number of barriers, including tension between federal and state privacy rights and blowback from tech giants.

While we wait to hear about the progression of this legislation, it is increasingly clear that if it does not become law in the near future, something will have to provide that modicum of oversight. To fully realize what kind of change will be effective, it is important to understand consumer perceptions around data security in the US, and for organizations to provide more visible safeguards in their digital services, in the meantime.

In a digital world, data privacy and security cannot take a backseat. With GDPR leading as example, there is not only a need for similar federal legislation in the US, but a calling for it from US consumers who are tired of finding out they are victim of another breach, leak, or attack. They are ready to take data protection seriously, and it is time we see some federal defenses put in place.

Data Security Concerns Are Driving Changes in US Consumer Behavior and Demands

No longer the realm of lone wolves, the world of cybercrime is increasingly strategic, commoditized, and collaborative.

Just as you keep up with the latest news, tools, and thought leadership in order to protect and secure your organization from cybercriminals, your adversaries are doing the same thing. They are connecting on forums, evaluating new software tools, talking with potential buyers, and searching for new ways to outsmart your security stack.

A peek into their world shows they have advanced capabilities that often outmaneuver well-funded security teams and corporate security tools, especially when pitted against legacy solutions like signature-based antiviruses. Many security operations centers (SOCs) fail to prioritize real threats, while wasting time trying to solve others that they can realistically never scale to meet.

Security defenders need to move beyond the mental image of the lone hooded figure sitting in a dimly lit basement as cigarette smoke wisps up from a dirty ashtray. Let's take stock of the world of cybercrime as it exists today: strategic, commoditized, and collaborative (especially if the criminals have money to spend).

**Strategic Intent Backs Every Attack**

Adversaries always have a business purpose; there’s a plan for every piece of malware. To begin, cybercriminals snoop around for access to your environment, looking for something they can steal and potentially resell to someone else. While an attacker may not know _exactly_ what they want to do once they gain access to your environment, they tend to recognize value when they see it.

They may perform reconnaissance by looking for misconfigurations or exposed ports to exploit, a process often made trivially easy by known CVE databases and free open-port scanners. Initial compromise can also be accomplished by stealing a user’s credentials to access the environment, a process that’s sometimes even easier, before moving laterally to identify key assets.

**The Cyber Weapons Black Market is Maturing**

Cybercriminals have developed a sophisticated underground marketplace. Tools have evolved from relatively inexpensive and low-tech products into those with advanced capabilities delivered via business models familiar to legitimate consumers, like software as a service (SaaS). Threat hunters are witnessing the commoditization of hacking tools.

Phishing kits, pre-packaged exploits, and website cloning tools used to be very common. Designed to mimic website login pages, such as Microsoft Office 365 or Netflix, these tools were quite effective at capturing users’ credentials for many years.

Over the past two decades, though, the security community responded to this type of activity with techniques like pattern recognition, URL crawling, and shared threat intelligence. Tools like VirusTotal have made it a common practice for the discovery of malicious files to be shared with the wider security community almost instantaneously. Naturally, adversaries are well aware of this and have adapted.

**A New Phishing Methodology**

Today’s adversaries have also learned to capitalize on the rise of multi-factor authentication (MFA) by hijacking the verification process.

One new type of phishing kit is called EvilProxy. Like kits of the past, it mimics website login pages to trick users into giving away their login credentials. Unlike phishing kits of the past that were sold as one-time purchases, this new methodology — sold by specialists in access compromise — operates via a rental model, whereby the seller rents out space on their own server for running phishing campaigns.

They host a proxy server that operates like a SaaS model. The service costs about $250 for 10 days of access. This allows the SaaS providers to make more money and enables them to collect statistics they can then publish on hacker forums to market their products and compete against other sellers.

New kits have built-in protections to defend their phishing environment from unexpected visitors. Since they obviously don’t want web crawlers indexing their sites, they use bot protection to block crawlers, nuanced virtualization detection technology to ward off security operations teams doing reconnaissance through a virtual machine (VM), and automation detection to prevent security researchers from crawling their kit websites from different angles.

**The “Adversary in the Middle” Scenario**

In the context of bypassing MFA, acting as a reverse proxy to the authentic login page content creates big problems for typical phishing detection. By sitting between the user and the target website, the reverse proxy server allows the adversary to gain access to the username, password, and session cookie that is set after MFA is completed. They can then replay the session back into a browser and act as the user on that destination.

To the user, everything looks normal. By using slight variations of names in the URLs, the cybercriminals can make the site seem completely legitimate, with everything working as it should. Meanwhile, they have gained unauthorized access through that user, which can then be exploited for their own purposes or auctioned off to the highest bidder.

**The Adversary’s Business Model**

In addition to new phishing methodologies, malware is sold openly on the Internet and operates in a sort of gray space, floating between legal and illegal. One such example is BreakingSecurity.net, which markets the software as a remote surveillance tool for enterprise.

Every piece of malware has a price point associated with it to drive an outcome. And these outcomes have a clear business intent, whether it’s to steal credentials, generate cryptocurrency, demand a ransom, or gain spy capabilities to snoop around a network infrastructure.

Nowadays the creators of these tools are partnering with the buyers through affiliate programs. Similar to a multi-level marketing scheme, they say to the affiliate buyer of the tool, “Come to me when you get in.” They even offer product guarantees and 24/7 support of the tool in exchange for splitting the profits. This allows them to scale and build a hierarchy. Other types of cybercriminal entrepreneurs sell pre-existing compromises to the highest bidder. There are multiple business models at play.

**Today’s Reality: Case for an Advanced Cloud Sandbox**

Security teams should understand what today’s adversaries do and how quickly their actions can play out. The advanced malware on the market now is even more severe than phishing. Whether it’s Maldocs that evade filters, ransomware, information stealers, remote access trojans (RATs), or post-exploitation tools that combine toolsets, threat actors are more advanced than ever before—and so are their business models.

Countermeasures based on standard sandboxes doesn’t provide much in the way of inline prevention. Detection that combines cloud and AI can stop the stealthiest threats inline, in real time, and at scale.

If you’re not evolving with adversaries, you're falling behind. Because today’s cybercriminals are as professional and on their game as you.

Read more _Partner Perspectives_ from Zscaler.

Of Exploits and Experts: The Professionalization of Cybercrime

Market drivers include new regulations, increasing automobile complexity, and new vehicle types.

**BOULDER, Colo., Dec. 1, 2022 /PRNewswire/ —** A new report from Guidehouse Insights explores the global market for automotive cybersecurity solutions.

Automotive cybersecurity is the protection of connected vehicle systems, including software and communication networks, from tampering of any kind. Underlying the need for automotive cybersecurity is the increasingly complex technology of modern vehicles. According to a new report from Guidehouse Insights, paralleling increasing sales of connected vehicles, the market for automotive cybersecurity solutions is expected to grow steadily over the next 10 years, with revenue reaching more than $445.4 billion by 2031.

"The outlook for the automotive cybersecurity market over the next 10 years is strong. With vehicles becoming more reliant on electronic-based features and greater connectivity, the need for protection is high and growing," writes report author Karen Marcus, research analyst with Guidehouse Insights. "Interconnected systems involve small computers, or electronic control units for specific functions, multiple communication protocols, internal and third-party software, automation features, and cloud connectivity. Each of these components alone and working together creates potential attack vectors that must be protected."

Automotive manufacturers and their suppliers are increasingly driven by new regulations that require them to integrate cybersecurity solutions as a condition of approval for new designs; often, they are working to update their processes and systems before regulations go into effect. Other market drivers include increasing automobile complexity, new vehicle types, and shared vehicle services. Barriers to growth include resistance from research and development teams, high rates of employee resignation, and a chip shortage, all of which impact the industry's ability to provide service as quickly or thoroughly as its leaders would like, according to the report.

The report, "Automotive Cybersecurity Market Overview," analyzes the global market for automotive cybersecurity solutions, examines the key technologies in vehicles that require protection, and looks at the competitive landscape. It provides market outlooks for annual vehicle sales and revenue across six world regions—North America, Western Europe, Eastern Europe, Asia Pacific, Latin America, and Middle East & Africa—during the ten-year analysis period 2022 to 2031. An executive summary of the report is available for free download on the Guidehouse Insights website.

**About Guidehouse Insights**

Guidehouse Insights, the dedicated market intelligence arm of Guidehouse, provides research, data, and benchmarking services for today's rapidly changing and highly regulated industries. Our insights are built on in-depth analysis of global clean technology markets. The team's research methodology combines supply-side industry analysis, end-user primary research, and demand assessment, paired with a deep examination of technology trends, to provide a comprehensive view of emerging resilient infrastructure systems. Additional information about Guidehouse Insights can be found at www.guidehouseinsights.com.

**About Guidehouse**

Guidehouse is a leading global provider of consulting services to the public sector and commercial markets, with broad capabilities in management, technology, and risk consulting. By combining our public and private sector expertise, we help clients address their most complex challenges and navigate significant regulatory pressures focusing on transformational change, business resiliency, and technology-driven innovation. Across a range of advisory, consulting, outsourcing, and digital services, we create scalable, innovative solutions that help our clients outwit complexity and position them for future growth and success. The company has over 15,000 professionals in over 55 locations globally. Guidehouse is a Veritas Capital portfolio company, led by seasoned professionals with proven and diverse expertise in traditional and emerging technologies, markets, and agenda-setting issues driving national and global economies. For more information, please visit www.guidehouse.com.

Guidehouse Insights Anticipates Market for Automotive Cybersecurity Solutions Will Grow to More Than $445 Billion by 2031

Ratings ranged from AAA to CC, with security effectiveness scores from 27% to 100%.

**AUSTIN, Texas, Dec. 1, 2022 /PRNewswire/ —** CyberRatings.org, the non-profit entity dedicated to providing transparency on cybersecurity product efficacy, has completed an independent test of eight market leading security vendors in its first-ever Cloud Network Firewall comparative evaluation. Forcepoint, Fortinet and Juniper's test reports were published earlier in the year, all with 'AAA' ratings. In this latest release of test reports, Check Point and Versa Networks received a 'AAA' rating. Palo Alto Networks received an 'AA,' Sophos an 'A,' and Cisco 'CC.'

The test covered capabilities considered essential in a firewall including basic routing, access control, SSL / TLS decryption, threat prevention (exploits), evasion, performance, stability and reliability, and management. Amazon Web Services (AWS) was the public cloud service chosen to run the test. Ratings were calculated using a scale from 0 to 800.

Key findings include:  

*   Cloud services assume a shared security model, where cloud providers are responsible for the infrastructure and customers are responsible for securing the applications running on the infrastructure.
*   Roughly 80% of web traffic is encrypted and firewall decryption is not on by default: Firewalls will not see/block attacks delivered via (encrypted) HTTPS unless configured to do so.
*   Security vendors are used to controlling the platform on which their products are installed. In the cloud, they do not have that control; vendors are learning how to operate under these new conditions and there will be challenges.
*   Supply Chain attacks are on the rise. Using the cloud means relying on third parties to maintain software supply chain integrity. APIs, code reuse, open-source libraries, not maintained code, and other shared resources introduce unknown risks.

Security effectiveness scores ranged from 27% to 100%. The security effectiveness tests verified how effectively the firewall protected control network access, applications, and users while preventing threats (exploits and evasions), blocking malicious traffic while under extended load, and remaining resistant to false positives. Exploit block rates ranged from 88.3% to 100%. All products achieved 100% for resistance to evasion techniques.

"Security is your problem, not Amazon's," said Vikram Phatak, CEO of CyberRatings.org. "If you are migrating your data center to the cloud, create a plan for securing it." Phatak added. "And if you needed a firewall for your data center, you probably need one for your cloud deployment."

There are different ways consumers can purchase security products for the cloud. The individual test reports reflect the bring-your-own-license model while the comparative report illustrates the pay-as-you-go pricing. Both pricing models provide consumers with options to compare pricing on items important to their own organizations.

The following products were evaluated:

**Check Point Cloud Network Firewall CloudGuard IaaS R81.20-581**

**AAA**

Cisco Firepower Threat Defense for AWS Version 7.2.0

CC

Forcepoint Cloud Network Firewall v6.11

AAA

Fortinet Cloud Network Firewall v7.0.5 Build 0304(GA)

AAA

Juniper Cloud Network Firewall 22.1R1.1

AAA

Palo Alto Networks Cloud Network Firewall PA-VM-AWS-10.2.2

AA

Sophos Cloud Network Firewall SFOS 19.0.0 GA-Build317

A

Versa Networks Cloud Network Firewall Versa-FlexVNF-21.2.3

AAA

To read the CyberRatings reports go to CyberRatings.org.

Cloud Network Firewall test tools were provided by Keysight (CyPerf and Breaking Point), and TeraPackets Threat Replayer.

**About CyberRatings.org**

CyberRatings.org is a non-profit 501(c)6 entity dedicated to quantifying cyber risk and providing transparency on cybersecurity product efficacy through testing and ratings programs. To become a member, visit www.cyberratings.org.

CyberRatings.org Announces Results from First-of-its-Kind Comparative Test on Cloud Network Firewall

Know what you need to fix today and what you don’t.

**EVERGREEN, Colo., December 1, 2022** **—** Phylum, The Software Supply Chain Security Company, today announced the addition of Automated Vulnerability Reachability to its software supply chain security platform capabilities. With the ability to focus only on fixing what matters_, s_ecurity pros can end the deluge of false positives and developers can innovate with greater speed and confidence. This new introduction, combined with Phylum’s ability to block and prioritize open-source code risks, provides organizations with the most comprehensive software supply chain security available in the market.

Vulnerabilities represent a clear and present danger to the integrity of the software supply chain, but the massive amount of noise and false positives that come with traditional detection methods drain resources and leave organizations overwhelmed.

"Vulnerability management has been a frustrating and persistent challenge for security teams for well over a decade. Phylum has automated the answer to the question, 'Do I actually call the code triggering this vulnerability?' Addressing this question reduces customer false positive vulnerability issues by 90% or more and enables security teams to engage their development teams with supply chain issues that truly matter," said Peter Morgan, co-founder and president of Phylum.

Most vulnerability management approaches do not account for the nuances of open-source libraries. In library code, the parts of the library used are just as important as the package name and version, and not accounting for this data results in an astronomically high false positive rate. For example, an organization might use a package for signing build packages that contains a known Heartbleed vulnerability. But since the organization is only using it for code signing and not using the part of OpenSSL where that vulnerability exists, it isn't reachable. The Phylum Platform recognizes this nuance and informs the user accordingly.

Organizations that use Phylum save precious developer time, make more critical fixes and improve overall security posture by leveraging:

1.  Deep source analysis and call tracing that identifies which vulnerabilities impact projects, and which ones don’t.
2.  Graph-powered analysis that identifies inter-package call paths to prioritize the most impactful bugs that need fixing.
3.  Automated, continuous policy enforcement that provides alerts if vulnerability functions change due to new development needs.

Since software projects are made up of anywhere from 70%-90% of open-source code, Phylum first blocks software supply chain attacks trying to enter environments from open-source packages. This alleviates the burden of having to do extensive remediation once source code is built. Automated Vulnerability Reachability then continuously monitors the code in the event any development, package or author changes result in new vulnerabilities.

The Phylum Software Supply Chain Security Platform is purpose-built to address persistent and evolving software supply chain security challenges. Regardless of the maturity stage of an appsec program, Phylum is designed to address immediate needs and scale with an organization to meet future needs.

Automated Vulnerability Reachability will be available in Q1 2023 via SaaS and On-Prem. Book a demo here.

**About Phylum**  
Phylum is on a mission to secure the universe of code. Its platform automates software supply chain security to block new risks, prioritize existing issues and allow users to only use open-source code that they trust. The company is built by a team of career security researchers and developers with decades of experience in U.S. Intelligence Community and commercial sectors. Phylum is the winner of the Black Hat 2022 Innovation Spotlight Competition and was named a Top Infosec Innovator by Cyber Defense Magazine. Learn more at https://phylum.io, read The Phylum Research Blog, and follow us on LinkedIn and Twitter.

Source

DARKReading