A dual Russian-Canadian citizen is being extradited to the US to face charges related to LockBit ransomware activities.

One of LockBit's alleged ringleaders has been arrested in Ontario, Canada and is on his way to the US to face charges related to ransomware attacks against at least a thousand victims, according to the Department of Justice.

Dual Russian-Canadian citizen Mikhail Vasiliev is accused of being behind LockBit ransomware, which first emerged in January 2020 and has grown into one of the most widely used variants in the world. According to the DOJ, members of the ransomware group have demanded at least $100 million in ransoms collectively, ultimately successfully extorting tens of millions from their victims.

Deputy Attorney General Lisa O. Monaco said in a statement about the charges that the DOJ hopes the arrest sends a clear message to other cybercriminals.

"This arrest is the result of over two-and-a-half-years of investigation into the LockBit ransomware group, which has harmed victims in the United States and around the world," Monaco said. "Let this be yet another warning to ransomware actors: working with partners around the world, the Department of Justice will continue to disrupt cyber threats and hold perpetrators to account. With our partners, we will use every available tool to disrupt, deter, and punish cybercriminals."

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

LockBit Bigwig Arrested for Ransomware Crimes

Five practical steps to up-level attack surface management programs and gain greater visibility and risk mitigation around the extended ecosystem.

Modern IT environments are purposefully designed to be dynamic, evolving organically through things such as cloud computing, Internet of Things (IoT) devices, and, for many organizations, through mergers and acquisitions and supply chain business relationships. While enabling greater business efficiency and effectiveness, often infrastructure and data are added ad hoc without looping in the IT team or adhering to organizational security policies. The result is unmanaged or unknown infrastructure within the technology ecosystem, which introduces hidden risk.

Most security teams will acknowledge a lack of visibility in this dynamic environment. Whether it's credentialed access or missing agents, it's common to have a gap in visibility. However, unknown unknowns present an even more significant visibility challenge in most organizations.

**What Is an Unknown-Unknown Asset?**

Let's start by defining what we mean by unknown unknowns, or assets of which the security and IT teams have no awareness. Unknown unknowns can be introduced in a multitude of ways. For example, well-meaning developers with the ability to provision cloud resources on a personal credit card can spin up new database instances.

Consider capable contractors who can spin up their own infrastructure but forget to limit access to the code on GitHub. Or the business partners (third- and Nth-party suppliers) that are not accounted for in the extended enterprise ecosystem. Mergers are another common way that "unknown unknowns" are introduced — when the often outdated list of IT infrastructure doesn't meet the current reality of the infrastructure state.

With supply chain compromise on the rise and increasing organizational sprawl, how can organizations manage and mitigate risk from unknown unknowns?

**Closing Attack Surface Visibility Gaps**

To solve for unknown unknowns, security teams need to establish mechanisms and processes to maintain an up-to-date inventory of all _known_ assets associated with their organization and the vulnerabilities that can be used by threat actors as entry points into the network. The more known about the organization, the more information to perform active and continuous search for unknowns, and even fewer unknown unknowns.

Below are five practical steps to closing visibility gaps:

1.  **Enumerate and continuously monitor the asset inventory:** Create a process and workflow for continuous asset discovery that delivers a comprehensive inventory. Assets include internal and external resources, cloud resources, employees, and the supply chain. Externally accessible assets are often targeted by threat actors for initial access (MITRE T1190) by exploiting known vulnerabilities. In situations where a zero-day is disclosed, the security team can leverage the inventory to answer these questions: "Do we have that technology in our ecosystem and, if so, where?" and "Are we running the vulnerable version of the technology?"
2.  **Determine ownership of assets:** Attribution plays a big role in providing relevant information to the security team. Receiving a list of assets that may or may not be owned by your organization will slow down the team as they triage false positives (out-of-scope assets). At the onset of asset discovery efforts, the inventory should be audited to determine what is directly managed vs. shared security model (where the management of the asset is outsourced to a provider – such as a cloud service or SaaS provider). Management becomes easier over time as a security team establishes the baseline understanding of asset ownership.
3.  **Enrich assets with intelligence to identify and prioritize critical and high-severity issues**: The faster vulnerabilities are identified, the faster the security team can respond. Indicators of compromise (IoCs) and Dark Web monitoring can inform a security team of malicious activity involving the brand or an asset. Analysis based on incident response and adversary research can help defenders respond and prioritize appropriately based on how a vulnerability is being leveraged and the impact of exploitation. Recommended sources include NIST National Vulnerability Database (NVD), CISA's Known Exploited Vulnerability catalog, and intelligence feeds from the private sector.
4.  **Remediate and harden at scale****:** Prioritizing remediation and hardening efforts on the entry points that present the most risk to the organization is crucial to mitigation strategies. Critical and high-severity security findings should be investigated and remediated immediately. Over the medium and long term, the security team needs to be aware of and monitor for lower severity vulnerabilities that are often overlooked but can be used in tandem with easier-to-exploit vulnerabilities. Assign responsibility to the lower-priority items and set expectations for quarterly reporting on progress.
5.  **Regularly review assets for unknown unknowns — and integrate your findings into steps 1–4**: Information is only valuable if it's used. As more data is collected about an organization's attack surface, the information needs to be distributed to the appropriate teams within the organization and incorporated into the operational workflows across the security operations center (SOC) or intelligence organization. For example, the SOC team can leverage the latest information about potentially compromised devices to take specific threat-hunting actions and then implement mitigation strategies.

Managing and mitigating risk from known threats is challenging enough for already over-stretched security teams. By following the steps above, organizations can uplevel their attack surface management programs and gain greater visibility into potential risk within their extended ecosystem as well.

**About the Author**

    

Jonathan Cran is head of engineering, Mandiant Advantage Attack Surface Management, at Mandiant and was the founder and CEO of Intrigue prior to its acquisition by Mandiant in 2021. An experienced entrepreneur and builder, he's passionate about delivering high-quality outcomes and data-driven solutions, particularly when they require significant technical leadership. He is constantly striving to understand customers' challenges and deliver elegant solutions. His background includes hands-on experience as a security practitioner and leadership roles at companies such as Kenna Security, Bugcrowd, and Rapid7.

Managing and Mitigating Risk From Unknown Unknowns

KmsdBot takes advantage of SSH connections with weak login credentials to mine currency and deplete network resources, as it gains a foothold on enterprise systems.

A just-discovered evasive malware takes advantage of a key Internet-facing protocol to gain entry onto enterprise systems to mine cryptocurrency, launch distributed denial-of-service (DDoS) attacks, and gain a foothold on corporate networks, researchers have found.  

Dubbed KmsdBot by researchers at Akamai Security Research, the botnet infects systems via a Secure Shell Protocol (SSH) connection with weak login credentials, according to a report published Thursday. SSH is a remote administration protocol that allows users to access, control, and modify their remote servers over the Internet.

The botnet poses the most risk for enterprises that have deployed cloud infrastructure, or corporate networks that are exposed to the Internet, says Larry Cashdollar, principal security intelligence response engineer at Akamai.

“Once this malware is running on your system, it essentially has a toehold into your network," he tells Dark Reading. "It has functionality to update and spread itself, so it's possible it can burrow itself deeper into your network and surrounding systems.”

The researchers observed KmsdBot — which is written in Golang as an evasive measure — targeting an "erratic" range of victims, including gaming and technology companies as well as luxury car manufacturers, Cashdollar wrote in a Nov. 10 report. Golang is a programming language that's attractive to threat actors because it's difficult for researchers to reverse engineer.

Moreover, once it infects a system, the botnet does not maintain persistence, allowing it further to evade detection. "It’s not often we see these types of botnets actively attacking and spreading, especially ones written in Golang," Cashdollar wrote.

**Attack on Gaming Company**

The researchers detected KmsdBot when it dangled an unusually open honeypot in the hopes of luring attackers. The first victim of the new malware they observed was an Akamai client — a gaming company called FiveM that allows people to host custom private servers for Grand Theft Auto online, they said.

In the attack, threat actors opened a user datagram protocol (UDP) socket and built a packet using a FiveM session token. UDP is a communication protocol used across the Internet for time-sensitive transmissions, such as video playback or DNS look-ups.

"This will cause the server to believe a user is starting a new session and waste additional resources besides network bandwidth," Cashdollar wrote.

The researchers also observed a range of other attacks by the bot that were less specifically targeted, they said. They included generic Layer 4 TCP/UDP packets with random data as a payload, or Layer 7 HTTP consisting of GET and POST requests to either the root path or a specified path set in the attack command, he said.

And while the bot does have cryptomining capability, researchers did not observe this particular aspect of its functionality — only the DDoS activity, Cashdollar added.

In general, KmsdBot has a wide attack surface, supporting multiple architectures including Winx86, Arm64, mips64, and x86\_64, researchers said. It uses TCP to communicate with its command-and-control infrastructure.

**Avoiding and Mitigating Bot Attacks**

Despite the danger it poses to enterprises, they can avoid falling victim to the botnet by using common network security best practices that they really should be implementing anyway, Cashdollar says.

"The best way to prevent getting infected is to either use key-based authentication and disable password logins, or make sure you're using strong passwords," he tells Dark Reading.

Indeed, password compromise — whether it's by using stolen credentials or cracking a company's weak protections — remains one of the top ways threat actors access enterprise systems.

Beyond strong passwords, security experts recommend multifactor authentication, as well as more advanced solutions to solve this persistent issue. However, it's advice that remains unheeded by users in many corporate settings, leaving networks exposed to threats such as KmsdBot. 

Other easy steps organizations can take to protect themselves, according to Cashdollar, include keeping deployed applications up to date with the latest security patches, as well as checking in on them from time to time to ensure they remain secure.

Evasive KmsdBot Cryptominer/DDoS Bot Targets Gaming, Enterprises

Cloud storage databases, often deployed as "rogue servers" without the blessing of the IT department, continue to put companies and their sensitive data at risk.

A string of household names lately have been responsible for misconfigured cloud storage buckets overflowing with wide-open data — once again shining a light on a cybersecurity problem for which there seemingly is no plug.   

Just last week, security researcher Anurag Sen revealed that an Amazon server had exposed data on the viewing habits of Amazon Prime members. During the same period, news and media conglomerate Thomson Reuters acknowledged that three misconfigured servers had exposed 3TB of data through public-facing ElasticSearch databases, according to Cybernews, which revealed the issues. 

And In mid-October, Microsoft acknowledged that it left a misconfigured cloud endpoint open that could expose customer data, such as names, email addresses, email content, and phone numbers.   

"The issue was caused by an unintentional misconfiguration on an endpoint that is not in use across the Microsoft ecosystem and was not the result of a security vulnerability," Microsoft said in its statement on the misconfigured server. "We are working to improve our processes to further prevent this type of misconfiguration and performing additional due diligence to investigate and ensure the security of all Microsoft endpoints."

And indeed, the leaks are caused by a variety of misconfigurations rather than any bugs — ranging from insecure read-and-write permissions to improper access lists and misconfigured policies — all of which could allow threat actors to access, copy, and possibly alter sensitive data from accessible data stores.

"The main concern with this kind of leak is the high impact, and that is why the threat actors go after misconfigured storage \[servers\] and buckets," says Ensar Şeker, CISO at SOCRadar, the cybersecurity firm that discovered the Microsoft issue. "Once they discover \[the accessible data\], the bucket might ... contain huge amounts of sensitive data for one tenant \[or\] numerous tenants."

The security impact of misconfigured storage is not a new issue. The problem regularly ranks in the top 10 security issues included in the popular Open Web Applications Security Project (OWASP) Top 10 security list. In 2021, Security Misconfiguration took the No. 5 spot, up from No. 6 in 2017. The annual "Data Breach Investigations Report," published by Verizon Business, also notes the outsized impact of misconfigured cloud storage: Human errors accounted for 13% of all breaches in 2021, with report noting that misconfiguration "heavily influenced" the result  

**Rogue Servers: A Stealth Cloud Security Problem**

Overall, 81% of organizations have experienced a security incident related to their cloud services over the past 12 months, with almost half (45%) suffering at least four incidents, according to Venafi. The increase in complexity of cloud-based and hybrid infrastructure, along with a lack of visibility into that infrastructure, has caused the increase in incidents, says Sitaram Iyer, senior director of cloud-native solutions at Venafi.

"Yes, misconfigured cloud storage is one of the primary reasons for data leaks — I do believe that this is a trend," he says. "The increase in this trend is most often due to misconfiguration related to access controls: While only authorized users need to be allowed access to cloud storage, a simple mistake in configuration often enables \[any\] authenticated users to gain access."

Yet, often misconfiguration is not the original sin — instead, a worker or developer will deploy a "shadow" server, a container or storage bucket not known to the information-technology department and, thus, not managed by the company. "Shadow" data — stored in cloned databases test environments, unmanaged backups, and data analysis pipelines — is the main threat, says Amit Shaked, CEO and co-founder of Laminar, a cloud data security platform.

"Because it is unknown, it is at extra risk for exposure, which makes it a popular target for adversaries," he says  

**Better DevOps Automation Could Help**

Companies should regularly monitor their cloud assets to detect when a datastore or storage bucket may have been exposed to the public internet. In addition, when deploying cloud storage, using infrastructure-as-code (IaC) configuration files not only automates deployments but helps eliminate errors, according to data from Snyk, a maker of security services for the software supply chain.

Adopting IaC reduces cloud misconfigurations by 70%, according to the firm.

"When IaC isn’t being used, or when runtime misconfigurations can’t be tied back to the IaC templates that were used to create and manage an environment, it’s common for the same vulnerability to appear over and over again after remediation," Manoj Nair, chief product officer at Snyk, said in a statement sent to Dark Reading.

Part of the issue continues to be the division of responsibilities between cloud providers and the business customers. While the responsibility for configuring cloud assets belong to the customer, the cloud service should make properly configuring a cloud asset as easy as possible, Venafi's Iyer says.

"Principle of least privilege must be adopted for every aspect of the data," he says. "Access to data must be provided as needed, with proper controls and authorization policies that tie it to a specific user or service account, and proper logging of access and notifications must be implemented."

Amazon, Microsoft Cloud Leaks Highlight Lingering Misconfiguration Issues

StackRox bridges network security and other gaps and makes applying and managing network isolation and access controls easier while extending Kubernetes' automation and scalability benefit.

To reap the full benefits of Kubernetes and microservices-based application architectures, organizations must transform how they implement security. This transformation often reveals gaps and silos across the development and operations teams and processes. Case in point: the gap between developers and the network security team.

Based on survey results from more than 300 DevOps, engineering, and security professionals, the "2022 State of Kubernetes Security Report" (PDF) shows that security is one the biggest concerns about container and Kubernetes adoption, with respondents noting that security issues have caused delays in deploying applications into production.

Almost all respondents to the survey, 93%, said they had experienced at least one security incident in their Kubernetes environment in the last 12 months, with 31% reporting a revenue or customer loss due to a security incident.

Most of these incidents come down to human error, with more than half (53%) of respondents saying they had detected a misconfiguration in Kubernetes in the last 12 months. There are many best practices for avoiding Kubernetes misconfigurations, but the reality is that Kubernetes is large and has a certain amount of complexity to it. Gaps among roles, responsibilities, and skill sets — common, especially for companies refactoring legacy applications — leave the door open to vulnerabilities.

For example, developers and the network security team may be working, if not at cross purposes, then in silos. Developers historically haven't been the ones to implement network security — they would just throw apps over the wall and rely on the security team to take care of network configuration.

In a Kubernetes world, however, the onus for security is on DevOps — or, at least, that's the perception. And, it makes sense that people would think like that: The whole notion of "shift left" is that security is addressed as early in the development cycle as possible.

Indeed, according to the survey, DevOps is the role most often cited as responsible for securing containers and Kubernetes: 15% of respondents consider developers as the primary owners of Kubernetes security, with only 18% identifying security teams as being most responsible.

But shifting left is not enough, especially when zero-day exploits are a relatively common occurrence. Only tight collaboration across development, IT operations, and network and other security teams can reasonably secure applications against attackers— especially those who are looking for points of entry from which they can move as far along the kill chain as possible.

Organizations likely understand all of this in theory, but in reality, there's a bit of a no-man's land when it comes to network security and Kubernetes: Who manages and understands and reviews network configuration within the cluster? Who is identifying and remediating misconfigurations ?

The gap between developers and the network security team can grow wider as companies move toward a zero trust model. With zero trust, of course, nothing is trusted. But businesses can't run that way. At some point, someone has to provide permissions to specific applications and services to communicate with each other.

**Kubernetes' NetSec Conundrum**

By default, Kubernetes deployments don't apply network policy to Kubernetes pods. Without network policies, any pod can talk to any other pod or network endpoint — the equivalent of a computer without a firewall. Someone must go in and define ingress and egress network policies that limit pod communication to defined assets.

In the past, developers indicated what communications paths needed to be made available, and network administrators made those paths available via traditional firewall configurations.

The problem is that network security engineers do not speak the Kubernetes language. In a Kube world, everything you do around network security needs to be written in YAML, a data serialization language, but network security engineers think in terms of IP addresses and IP tables. The NetSec team doesn't really understand the language that policies are written in, and the tools aren't familiar to them.

One tool that bridges network security and other gaps is StackRox, a cloud-native open source project that provides organizations with tools, training, and a community of shared experiences with building Kubernetes security implemented as security policies that can be used to monitor Kubernetes clusters and the workloads running on those clusters.

When it comes to network configuration, StackRox enables developers and security teams to visualize existing versus allowed network traffic. Using Kubernetes-native controls, NetSec teams can then more effectively enforce network policies and tighter segmentation. StackRox recently added a new feature to help developers define network policies prior to deploying their application to Kubernetes. This was developed in partnership with the developers of the np-guard project. StackRox roxctl now has the option to call np-guard to generate network policies by analyzing resource YAMLs.

With the StackRox project, organizations can address all significant security use cases across the entire application life cycle. Apropos of what I mentioned above, StackRox eases the process of applying and managing network isolation and access controls for applications. Other use cases include:

**Vulnerability management:** StackRox helps organizations protect against known vulnerabilities by identifying vulnerabilities in images and running containers.

**Security configuration management:** Organizations can leverage StackRox to ensure that Kubernetes is configured according to security best practices.

**Risk profiling:** StackRox provides the context needed to prioritize security issues throughout Kubernetes clusters by analyzing a variety of data about deployments.

**Compliance:** Organizations can leverage StackRox's compliance policies to meet contractual and regulatory requirements.

**Detection and response:** StackRox provides incident response capabilities, enabling organizations to address active threats in their environments.

In general, using Kubernetes-native controls such as StackRox — in other words, using the same infrastructure and its controls for application development and security — enables companies to go from shifting security left to shifting it to a 360-degree cycle, all while extending Kubernetes' automation and scalability benefits.

You can download StackRox from GitHub here. There you will also find related projects such as KubeLinter, a static analysis tool that enables developers to easily check Kubernetes YAML files, and Helm charts to identify misconfigurations and enforce security best practices.

How to Close Kubernetes' Network Security Gap

Links individual vulnerabilities to those known to have been used in ransomware operations, helping vulnerability management teams prevent potential cyber extortion events with VulnDB.

**NEW YORK, NY – November 9, 2022** **—** Flashpoint, the globally trusted leader in risk intelligence, announced today an industry-first ransomware prediction model that allows vulnerability management teams to improve remediation efforts and prevent cyber extortion events with VulnDB, the most comprehensive vulnerability database available on the market.

According to the U.S. Treasury Department, financial institutions filed $1.2B in ransomware-related costs in 2021, nearly double the amount reported by banks in 2020. In order to help organizations proactively prevent a ransomware attack, Flashpoint’s latest capability enables vulnerability management teams to identify the likelihood that a particular vulnerability could be used in a future ransomware attack.

“The risk of falling victim to a ransomware attack can be radically reduced with the right intelligence,” says Flashpoint General Manager Jake Kouns. “Our ransomware prediction algorithm, coupled with our vulnerability intelligence, is a must-have for security teams that want to remediate vulnerabilities that could help them get in front of a potentially destructive ransomware attack.”

VulnDB covers over 300,000 known vulnerabilities found in end-user software and third-party libraries and dependencies, including over 96,000 vulnerabilities missed by CVE and NVD. For each of those vulnerabilities, including newly disclosed issues, Flashpoint’s ransomware prediction model determines a Ransomware Likelihood rating that’s derived from a combination of factors, including exploit availability, attack type, impact, disclosure patterns, and other characteristics captured by VulnDB. This intelligence is critical to vulnerability management teams who often lack the resources and context they need to efficiently prioritize and patch tens of thousands of vulnerabilities disclosed every year.

To learn more about Flashpoint’s ransomware prediction model and VulnDB, reach out for a free trial.

****About Flashpoint****

Trusted by governments, commercial enterprises, and educational institutions worldwide, Flashpoint helps organizations protect their most critical assets, infrastructure, and stakeholders from security risks such as cyber threats, ransomware, fraud, physical threats, and more. Leading security practitioners—including physical and corporate security, cyber threat intelligence (CTI), vulnerability management, and vendor risk management teams—rely on the Flashpoint Intelligence Platform, comprising open source (OSINT) and closed intelligence, to proactively identify and mitigate risk and stay ahead of the evolving threat landscape. Learn more at flashpoint.io.

Flashpoint Releases Ransomware Prediction Model for Vulnerabilities

Technology consolidates Windows and Linux software risk together in one UI, helping teams manage vulnerabilities and comply with new regulatory standards.

**BE’ER SHEVA, Israel, (November 9, 2022) —** Rezilion, an automated software security platform, announced today the expansion of its Dynamic Software Bill of Materials (SBOM) capability to support Windows environments. Through this expansion, Rezilion will provide organizations with a first-of-its-kind toolset to efficiently manage software vulnerabilities and meet new regulatory standards, for the 56% of software today that’s built for Windows OS.

“We are seeing a widespread interest in adopting SBOMs as many organizations realize that their future security, risk, and compliance posture relies heavily on the need to see into their software supply chain,” said Liran Tancman, CEO, Rezilion. “A Dynamic SBOM that supports Windows environments widens the scope of possibility and gives the ability to a massive number of new customers to meet regulatory standards and detect and manage their software vulnerabilities strategically.”

While many tools exist for organizations to manage vulnerabilities in their software, the vast majority of these were initially built for use with Linux OS, resulting in gaps in functionality when they’re used for Windows. A dearth of “Windows-first” tooling also affects organizations’ preparedness to comply with new regulations such as the President’s Executive Order (EO) 14028, which will require teams to provide regulators with a thorough inventory of their software environments and related vulnerabilities.The market has been alarmingly slow to respond to this increasingly urgent need for better solutions. As evidence of this, Microsoft itself released its first, basic, open source “Windows-first” SBOM generation tool as recently as July of this year.

As a result of these gaps, for organizations with large, legacy Windows environments (including critical infrastructures), a new threat on the scale of the “Y2K” scare of the late 1990’s is emerging. Be it attackers or regulators, these organizations must modernize their security standards, or suffer consequences of looming risks ahead.

First released in May, Rezilion’s Dynamic SBOM can be deployed in all software environments – both Windows and Linux simultaneously – and provides a real-time versus static inventory of all software components in a single graphical UI. Rezilion’s solution also integrates dynamic runtime analysis to not only detect software vulnerabilities, but validate their actual exploitability, helping teams to clear away “false-positive” scan results and avoid wasteful patching work that shifts resources away from build activity.

Other key features and capabilities include:

*   **Dynamic Identification** – Instantly search and pinpoint vulnerable components such as Log4J across millions of files and on thousands of hosts, containers, and applications.
*   **Holistic Insight & Control** – View Windows and Linux risk side by side in one UI, to get a complete picture of your attack surface, manage risk efficiently and comply with auditors
*   **Tackle Legacy Vulnerability Backlogs Efficiently** – Aggregate detected vulnerabilities, filter out false-positives and prioritize what matters to address risks quickly and meet modern remediation SLAs as defined by CISA with a fraction of the effort

Learn more about Rezilion’s Dynamic SBOM at https://www.rezilion.com/platform/dynamic-sbom/.

Book a demo today to learn more about Rezilion’s Windows software security solutions a https://www.rezilion.com/lp/windows-security-demo/.

**About Rezilion**

Rezilion’s platform automatically secures the software you deliver to customers. Rezilion’s continuous runtime analysis detects vulnerable software components on any layer of the software stack and determines their exploitability, filtering out up to 95% of identified vulnerabilities. Rezilion then automatically mitigates exploitable vulnerabilities across the SDLC, reducing vulnerability backlogs and remediation timelines from months to hours while giving DevOps teams time to build.

Rezilion Expands Dynamic SBOM Capability to Support Windows Environments

Greater insight into attack paths and runtime visibility helps customers reduce risk and improve cloud security posture.

**San Jose, Calif., November 9, 2022 —** Lacework®, the data-driven cloud security company, today announced new cloud-native application protection platform (CNAPP) capabilities for the Polygraph® Data Platform that provide improved attack path analysis and agentless workload scanning for secrets and vulnerabilities. These capabilities provide better visibility into today’s increasingly complex security environment, enabling organizations to instantly understand what matters so they can triage and respond faster.

According to the latest Lacework Cloud Threat Report, attackers are rapidly increasing in sophistication, with a particular focus on infrastructure. Attackers constantly seek paths of least resistance to compromise a system, hiding in the complexity of seemingly disparate risks and exploiting them whenever possible. Despite cloud adoption becoming nearly ubiquitous across industries, many enterprises still lack the visibility needed to truly manage and understand these sophisticated vulnerabilities present or emerging in their own cloud environments. Even most modern security solutions fall short here, relying on rules-based approaches that don’t account for the dynamic uniqueness of each organization’s cloud environment.

“As cloud environments become more complex, it’s difficult for organizations to get a clear picture of what is happening across their critical infrastructure so they can work efficiently to scale security to manage risk with the speed of modern software development,” said Melinda Marks, Senior Analyst at ESG. “Lacework is a strong player in the CNAPP category because it combines visibility with a deep understanding of behaviors across a customer’s overall cloud environment.”

In response to these challenges, Lacework has introduced **attack path analysis**, which combines a visual representation of potential attack paths with deep runtime insight from the Polygraph Data Platform. These visual attack paths tie together different attack vectors, including vulnerabilities, misconfigurations, network reachability, secrets, and identity and access management (IAM) roles for every host in the environment. This is provided as an additional layer of context for every alert to clearly show which assets could be attacked and why. As cloud threats continue to grow in volume and sophistication, this critical context enables security teams to identify and prioritize remediation based on risk and actively watch for exploits before they become a problem, all from a single platform.

With the addition of **agentless workload scanning**, customers benefit from more flexibility to build layered security, broader coverage across environments, and faster time to value through vulnerability and secrets discovery in runtime environments without the use of agents. Customers can now assess vulnerabilities and exposed secrets in container images, hosts, and language libraries and deliver a software bill of materials for their runtime environment. This enables:

*   A better understanding of the cloud environment and potential risks with an up-to-date inventory of software components and information about vulnerabilities and exposed secrets in the production environment
*   The ability to scan more resources without an agent for more complete coverage of the runtime environment and to stay compliant with security standards and business needs
*   More flexibility and choice to build layered security with continuous monitoring

“We take security seriously and always consider it a critical factor when we build or deploy new services, “ says Charly Vitrano, Director of Security Operations at Medallia. “Lacework has given the market a new, better, and more secure option for agentless scanning — the privacy and least privilege elements were essential for us to deploy this solution across our environment.”

“In order to provide a complete, robust security solution, customers need both visibility into the risks to prioritize fixing across the entire cloud environment and deep insight into what’s actively happening across their environment so they can take action quickly to protect their business,” said Adam Leftik, VP of Product, Lacework. “We knew delivering only risk prioritization wasn’t good enough, which is why we’ve incorporated advanced visibility and protection from active attacks into our Polygraph Data Platform. Customers now have the context they need to ensure their environments stay safe even as threats continue to grow.”

Lacework is the only security platform that combines the ability to see potential risks from the lens of an attacker with the knowledge of what’s actively happening to uncover attacks without needing to write a single rule. This enables customers to prioritize mitigating the most impactful attack vectors and automatically detect if or when they are exploited.

Attack path analysis and agentless vulnerability scanning are now generally available to Lacework customers. Visit our website to get started today.

Additional Resources:

*   To learn more and to request a demo, please visit our website: www.lacework.com/
*   Check out our blog for more information on our new agentless scanning capabilities.

Read what Lacework customers have to say about the Lacework Polygraph Data Platform.

Lacework Extends CNAPP Capabilities With Attack Path Analysis and Agentless Workload Scanning

Risk-based vulnerability management solutions foster the convergence of risk management and vulnerability management. Andrew Braunberg explains what’s driving the emergence of RBVM.

A change is underway in the vulnerability management market. Traditional vulnerability management solutions are giving way or morphing into a new segment, called risk-based vulnerability management, or RBVM.

Addressing the scale of the vulnerability problem has been a growing concern, as first-generation vulnerability management tools have increasingly overwhelmed users with endless lists of vulnerable assets.

This version of alert fatigue led vendors to examine how a risk-based approach might inform better vulnerability prioritization and response. Instead of trying to figure out how to patch everything faster, RBVM vendors tackle the scale problem by calculating what to patch and what to ignore.

RBVM addresses more than just the scaling problem, however. For example, while legacy internal scanners remain important tools, many of today’s digital assets operate beyond the view of these tools. Similarly, the Common Vulnerability Scoring System (CVSS) is still of value but is now just one of many data points to consider when assessing and prioritizing risk. Modern RBVM solutions leverage what has worked traditionally, while introducing new capabilities, including advanced analytics, as needed, to advance the discipline.

**The Heart of RBVM**

The goal of better understanding and assessing risk is at the heart of RBVM solutions. Not surprisingly, these products are chiefly marketed as providing prioritized risk rankings for vulnerabilities, with the goal of identifying the risk posed by each and determining the next best action.

A related benefit of this risk-based approach is a recognition of which actions can be delayed or ignored altogether. For example, software vulnerabilities can be categorized based on the risk they pose to the organization; those deemed low risk can be put off and addressed as time allows, enabling security and IT operations teams to focus efforts on high-risk vulnerabilities. RBVM solutions, therefore, address both effectiveness and efficiency.

RBVM solutions are designed to leverage existing IT infrastructure. For example, IT service management (ITSM) deployments have become much more prevalent in the last decade and often support patch management features. For RBVM solutions, this means that integration with these existing legacy solutions is often more important than providing an end-to-end vulnerability management solution.

Hence, Omdia believes the most impactful RBVM solutions will not only foster convergence of risk management and vulnerability management but also easily complement and enhance both new and existing enterprise vulnerability management programs.

RBVM is part of a broader rethinking of cybersecurity that emphasizes a more proactive approach to the problems practitioners face. The goal with RBVM is to avoid breaches by eliminating high-risk vulnerabilities, and continuously reducing an organization’s attack surface.

While to be sure, legacy vulnerability management aimed to be proactive as well, RBVM attempts to be both more efficient and effective. RBVM is a topic that enterprises will hear much more about in the months to come.

_Note: Omdia Security Operations Intelligence Service subscribers may read Andrew Braunberg’s full report here: Fundamentals of Risk-Based Vulnerability Management._

Understanding the Rise of Risk-Based Vulnerability Management

The malicious package downloads an image from the Web, then uses a steganography module to extract and execute the code to download malware.

Check Point Research has detected a malicious open source code package that uses steganography to hide malicious code inside image files.

The malicious package was available on PyPI, a package index widely used by Python developers. After being notified of it, PyPI's maintainers have removed the malicious package.

The malicious package, apicolor, looks like one of many development packages available on PyPI. The header states the package is a "core lib for REST API." The package installation script for apicolor has instructions to download additional packages (requests and judyb), along with a picture from the Web. The script then uses the steganography capabilities in judyb to uncover and execute the malicious code hidden inside the image file. The malicious code downloads malware from the Web and installs it on the user's machine.

The impact seems minimal — Check Point Research found only three GitHub users including apicolor and judyb in their code, and a little over 80 projects containing the malicious packages. The infection method relies on people stumbling across these open source projects and installing them on their machines, "not knowing it brings in a malicious package import," the team said.

The more important takeaway? "These findings reflect careful planning and thought by a threat actor, who proves that obfuscation techniques on PyPI have evolved," Check Point Research wrote on the team's blog.

Attackers are no longer just relying on the strategy to copy and rename existing packages and hide malicious code inside. Instead, they are targeting certain type of users — often those working from home, and those using corporate machines for side projects, according to the research team.

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

Subscribe

Source

DARKReading