Half-day virtual Authenticate Summit to educate on how passkeys can fit into a variety of enterprise environments.

**MOUNTAIN VIEW, Calif.****,** **June 27, 2023** **/PRNewswire/ --** Passkeys are a game changer for signing in to online services and apps, providing phishing-resistant security and easy user experience far superior to passwords and other phishable forms of authentication. Enterprises globally are interested in passkeys but may be wondering: how do I start? And "what type of passkey is right for my environment?"

The FIDO Alliance addresses these questions in a new series of papers providing considerations for leveraging passkeys across different enterprise use cases. The series was developed by the FIDO Alliance's Enterprise Deployment Working Group (EDWG) and can be found at https://fidoalliance.org/fido-in-the-enterprise/. 

The papers in the series are:

*   FIDO Deploying Passkeys in the Enterprise – Introduction
*   Replacing Password-Only Authentication with Passkeys in the Enterprise
*   FIDO Authentication for Moderate Assurance Use Cases
*   High Assurance Enterprise FIDO Authentication

A fifth paper in the series, "Displacing Password + SMS OTP Authentication with Passkeys," is expected to publish later this summer.

"Passkeys are a new concept to many enterprise organizations, in terms of both terminology and FIDO authentication capabilities," said Andrew Shikiar, executive director and CMO of the FIDO Alliance. "These papers demystify synced and device-bound passkeys and provide the decision points for how to leverage them across a variety of use cases, whether they are using passwords alone, legacy MFA or FIDO-based solutions today. These papers provide a great foundation for anyone looking to understand how passkeys can increase their organization's security posture, meet legal and regulatory requirements and decrease support and other costs associated with authentication."

**Get an Overview Live at Authenticate Virtual Summit: Considerations for Passkeys in the Enterprise**

Those interested in this topic are encouraged to join the FIDO Alliance and members of its Enterprise Deployment Working Group on June 29, 2023 at 9:00 am PT / 12:00 pm ET for the free Authenticate Virtual Summit: Considerations for Passkeys in the Enterprise to learn how passkeys can fit into a variety of enterprise environments.

Sessions will cover introductory material, considerations across various use cases, and criteria to evaluate how synced passkeys and device-bound passkeys can meet varying legal, regulatory, and security requirements across enterprise environments.

Learn more and register for the free virtual summit at https://authenticatecon.com/event/passkeys-in-the-enterprise/.

**About the Enterprise Deployment Working Group (EDWG)**

The FIDO Alliance's Enterprise Deployment Working Group (EDWG) aims to accelerate enterprise deployments of FIDO solutions and advance the FIDO Alliance's vision for a strong, interoperable modern authentication ecosystem. The EDWG acts as a group of subject matter experts and internal advisors within the FIDO Alliance on issues affecting the deployment of FIDO solutions at the enterprise level. FIDO Alliance members interested in joining the EDWG can contact \[email protected\] for information on how to participate.

**About the FIDO Alliance**

The FIDO (Fast IDentity Online) Alliance, www.fidoalliance.org, was formed in July 2012 to address the lack of interoperability among strong authentication technologies, and remedy the problems users face with creating and remembering multiple usernames and passwords. The FIDO Alliance is changing the nature of authentication with 

standards for simpler, stronger authentication that define an open, scalable, interoperable set of mechanisms that reduce reliance on passwords. FIDO Authentication is stronger, private, and easier to use when authenticating to online services.

FIDO Alliance Publishes Guidance for Deploying Passkeys in the Enterprise

Saudi Arabia is one of the world's leaders in cybersecurity development and preparedness, according to the latest rankings.

The Kingdom of Saudi Arabia has secured second place in the Global Cybersecurity Index in the World Competitiveness Yearbook for 2023.

According to the International Institute for Management Development, the development of a National Cybersecurity Authority (NCA) and the planned development of a Global Cybersecurity Forum institute in the country have both affirmed Saudi Arabia's role in the field of cybersecurity.

The Kingdom also ranked 17th overall in 2023 — jumping by seven places from 2022 — in the competitiveness ranking, the Saudi Press Agency reported.

The International Telecommunications Union (ITU) has also designated Saudi Arabia as a global leader in cybersecurity, ranking Saudi Arabia also second on its Global Cyber Security Index.

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

Saudi Arabia's Cyber Capabilities Ranked Second Globally

Developers' enthusiasm for ChatGPT and other LLM tools leaves most organizations largely unprepared to defend against the vulnerabilities that the nascent technology creates.

Organizations' rush to embrace generative AI may be ignoring the significant security threats that large language model (LLM)-based technologies like ChatGPT pose, particularly in the open source development space and across the software supply chain, new research has found.

A report by Rezilion released June 28 explored the current attitude of the open source landscape to LLMs, particularly in their popularity, maturity, and security posture. What researchers found is that despite the rapid adoption of this technology among the open source community (with a whopping 30,000 GPT-related projects on GitHub alone), the initial projects being developed are, overall, insecure — resulting in an increased threat with substantial security risk for organizations.

This risk only stands to increase in the short-term as generative AI continues its rapid adoption throughout the industry, demanding an immediate response to improve security standards and practices in the development and maintenance of the technology, says Yotam Perkal, director of vulnerability research at Rezilion.

"Without significant improvements in the security standards and practices surrounding LLMs, the likelihood of targeted attacks and the discovery of vulnerabilities in these systems will increase," he tells Dark Reading.

As part of its research, the team investigated the security of 50 of the most popular GPT and LLM-based open source projects on GitHub, ranging in length of development time from two to six months. What they found is that while they were all extremely popular with developers, their relative immaturity was paired with a generally low security rating.

If developers rely on these projects to develop new generative-AI-based technology for the enterprise, then they could be creating even more potential vulnerabilities against which organizations are not prepared to defend, Perkal says.

"As these systems gain popularity and adoption, it is inevitable that they will become attractive targets for attackers, leading to the emergence of significant vulnerabilities," he says.

**Key Areas of Risk**

The researchers identified four key areas of generative AI security risk that the adoption of generative AI in the open source community presents, with some overlap between the groups:

*   Trust boundary risk; 
*   Data management risk; 
*   Inherent model risk; 
*   And basic security best practices.

_**Trust boundaries**_ in open source development help organizations establish zones of trust in which they can have confidence in the security and reliability of an application's components and data. However, as users enable LLMs to use external resources such as databases, search interfaces, or external computing tools — thus greatly enhancing their functionalities — the inherent unpredictability of LLM completion outputs can be exploited by malicious actors.

"Failure to address this concern adequately can significantly elevate the risks associated with these models," the researchers wrote.

_**Data-management risks**_ such as data leakage and training-data poisoning also expose enterprises to risk if not addressed by developers when working not just with generative AI, but any machine-learning (ML) system, the researchers said. Not only can LLM unintentionally leak sensitive information, proprietary algorithms, or other confidential data in its responses, threat actors also deliberately can poison an LLM's training data to introduce vulnerabilities, backdoors, or biases that can undermine the security, effectiveness, or ethical behavior of the model, the researchers warned.

_**Inherent underlying model risks**_ meanwhile account for two of the top LLM security problems: inadequate AI alignment and overreliance on LLM-generated content. "In fact, OpenAI, the creator of ChatGPT, warns its users about these risks in the main ChatGPT interface," the researchers noted in the report.

These risks refer to the phenomenon of generative AI like ChatGPT returning false or fabricated data sources or recommendations, commonly called "hallucinations," which researchers from Vulcan Cyber's Voyager18 already have warned could open up organizations to supply-chain attacks. This can occur when a developer asks ChatGPT or another generative AI solution from recommendations for code packages that don't exist, both Vulcan and Rezilion researchers noted. An attacker can identify this and publish a malicious package as a substitute, which developers will then use and write directly into an application.

Other users, unaware of the malicious intent, can then pose similar questions to ChatGPT, and the risk spreads from there across the supply chain because the AI model is unaware of the code manipulation, they noted. "Consequently, unsuspecting users may unknowingly adopt the recommended package, putting their systems and data at risk," the researchers wrote.

And finally, general security best-practice risk stems from open source adoption of generative AI, in the areas of improper error handling or insufficient access controls (which are not unique to LLMs or ML models). An attacker can exploit the information in the LLM error messages to gather sensitive information or system details, which they can then use to launch a targeted attack or exploit known vulnerabilities, the researchers said. And insufficient access controls also could allow users with limited permissions to perform actions beyond their intended scope, potentially compromising the system.

**How Organizations Can Prepare, Mitigate Risk**

Rezilion researchers presented specific ways that organizations can mitigate each of these risks, as well as overall advice for how they can prepare as the open source community continues to embrace these models for next-generation software development.

The first step to this preparation is an awareness that integrating generative AI and LLMs comes with unique challenges and security concerns that may be different than anything organizations have encountered before, Perkal says. Moreover, the responsibility for preparing and mitigating LLM risks lies not only with organizations integrating the technology but also the developers involved in building and maintaining these systems, he notes.

As such, organizations should adopt what Perkal calls a "secure-by-design" approach when implementing generative AI-based systems, he says. That entails leveraging existing frameworks like the Secure AI Framework (SAIF), NeMo Guardrails, or MITRE ATLAS to incorporate security measures directly into their AI systems, Perkal says.

It's also "imperative" that organizations monitor and log LLM interactions and regularly audit and review the AI system's responses to detect potential security and privacy issues, and then to update and tweak the LLM accordingly, he concludes.

Generative AI Projects Pose Major Cybersecurity Risk to Enterprises

With the National Cybersecurity Strategy planning to add real teeth into enforcement actions, software vendors have extra incentive to reduce applications' security debt.

We're in the midst of a transformational shift in software security. Companies will soon bear responsibility for insecure software and can no longer play the victim card.

Recently, President Biden's administration released its long-awaited National Cybersecurity Strategy, created with the hope to "secure the full benefits of a safe and secure digital ecosystem." As expected, it focuses to a large extent on software security and who should be liable for its vulnerabilities. Stating that "markets impose inadequate costs on — and often reward — entities that introduce vulnerable products or services," the strategy calls for making organizations more liable for shipping insecure software.

Putting aside the debate about regulation versus market forces, it's hard to argue with the strategy's implicit assertion that insecure software code is endemic. As security professionals, it's our job to examine why insecure software is so prevalent and understand how to address it. Furthermore, with this plan, software security would no longer be a nice-to-have: Companies will be liable for the security of their products. Therefore, now is the time to bring rigor to software security.

**The Root of Vulnerabilities**

Insecure software often starts at the beginning, where flaws are introduced. But before diving in, it's important to be clear about the terminology.

A "flaw" is an implementation defect introduced when code is written that can lead to a "vulnerability" — an exploitable condition within software code that opens the door to an attack. Flaws accumulate over time resulting in "security debt" — the flaws you don't fix over the lifetime of an application. Security debt has been an important driver in the rise of DevSecOps, which integrates security throughout the software development life cycle.

Veracode's most recent "State of Software Security" research report took a fine-grained look at the factors contributing to flaw introduction, using data drawn from static analysis of more than 750,000 applications.

It found that no matter the size, applications grow steadily at about 40% a year through the first five years. But the rate of new flaw introduction follows a different pattern. When a new application is onboarded, the number of flaws undergoes a precipitous drop, most likely as an initial scan discovers accumulated flaws. The app then enters the "honeymoon phase" through the first year and a half, during which nearly 80% of applications introduce no new flaws. When the honeymoon ends, however, the introduction of flaws grows steadily until plateauing around year five.

The most common flaws discovered vary widely depending on the type of scan conducted, as static, dynamic, and software composition analyses involve different techniques and can detect different issues. There was some overlap among the top flaws found — information leakage showed up in all three — but there were enough differences to underscore the importance of using multiple scan types.

Scan frequency also has an impact. We found a marked reduction in both the probability of new flaws and the actual number of them when scans were performed the previous month. Using application programming interfaces (APIs) to automate the scanning process was also beneficial in reducing the probability and number of flaws.

**Stepping Toward More Secure Applications**

Preventing all flaws from being introduced in the first place would be ideal, but it's just not practical. Our research uncovered three recommendations for making applications more secure.

Our first piece of guidance is to remediate security flaws as early and quickly as possible. By the time an application is two years old, we see applications increasingly accumulating flaws. It's clear that something happens to the application or to the groups developing them. Whether increasing application complexity from years of steady growth or diminishing focus on production applications over time, this familiar pattern of an upwards slant, shown in our research, is clear.

Our next piece of guidance is to prioritize automation and developer training. Awareness of the most common flaws and how they are introduced makes a notable difference in reducing their numbers. We saw this in results from organizations whose developers had completed 10 hands-on security training courses. Our research found that completion of 10 training courses correlates to a 12% reduction in the number of flaws introduced.

Lastly, companies need to establish application life-cycle management. Establishing who owns an application will help keep it secure, but don't try to make a comprehensive list upfront, because you'll never finish it. It would be better to start with the necessary information for a few applications and build the list iteratively from there.

Maintaining an application isn't just a matter of deciding whether it's needed, but also how long it should be in production. This is important given the growth of flaws that occur over time and the amount of attention that will be paid to it in later years.

**Rigor Is a Requirement**

In today's security climate, software security is paramount. With the National Cybersecurity Strategy planning to add real teeth into enforcement actions, software vendors have extra incentive to reduce the security debt of their applications.

Understanding how flaws are created and how best to remediate them can help ensure both the security and viability of software products.

Rigor in software security means being thorough at every stage of the modern software development life cycle as the shift of responsibility turns to you.

3 Strategies for Bringing Rigor to Software Security

New LLM-based projects typically become successful in a short period of time, but the security posture of these generative AI projects are very low, making them extremely unsafe to use.

There is a lot of interest in integrating generative AI and other artificial intelligence applications into existing software products and platforms. However, from a security standpoint these AI projects are fairly new and immature, exposing organizations using these applications to various security risks, according to recent analysis by software supply chain security company Rezilion.

Since ChatGPT’s debut earlier this year, more than 30,000 open source projects now use GPT 3.5 on GitHub, which highlights a serious software supply chain concern: How secure are these projects that are being integrated left and right?

Rezilion’s team of researchers attempted to answer that question by analyzing the 50 most popular Large Language Model (LLM)-based projects on GitHub – where popularity was determined by how many stars the project has. The project's security posture was measured by the OpenSSF Scorecard score. The Scorecard tool, from the Open Source Security Foundation, assesses the project repository on various factors, such as the number of vulnerabilities it has, how frequently the code is being maintained, its dependencies, and the presence of binary files, to calculate the score. The higher the number, the more secure the code.

The researchers mapped the project’s popularity (size of the bubble, y-axis) and security posture (x-axis). None of the projects analyzed scored higher than 6.1 – the average score was 4.6 out of 10 – indicating a high level of security risk associated with these projects, Rezilion said. In fact, Auto-GPT, the most popular project (with almost 140,000 stars), is less than 3 months old and has the third-lowest score of 3.7, making it an extremely risky project from a security perspective.

When organizations are considering which open source projects to integrate into their codebases or which ones to work with, they consider factors such as whether the project is stable, currently supported, actively maintained, and the number of people actively working on the project. Organizations have to consider several types of risks, such as trust boundary risks, data management risks, and inherent model risks.

"When a project is new, there are more risks around the stability of the project, and it’s too soon to tell whether the project will keep evolving and remain maintained,” the researchers wrote in their analysis. “Most projects experience strong growth in their early years before hitting a peak in community activity as the project reaches full maturity, then the level of engagement tends to stabilize and remain consistent.”

The age of the project was relevant, Rezilion researchers said, noting that most of the projects in the analysis were between 2 and 6 months old. When the researchers looked at both the age of the project and Scorecard score, the age-score combination that was the most common was projects that are 2 months old and have a Scorecard score of 4.5 to 5.

"Newly-established LLM projects achieve rapid success and witness exponential growth in terms of popularity,” the researchers said. “However, their Scorecard scores remain relatively low.”

Development and security teams need to understand the risks associated with adopting any new technologies and make a practice of evaluating them prior to use.

Open Source LLM Projects Likely Insecure, Risky to Use

Cl0p ransomware group uses its Dark Web leak site to identify five new victims of MOVEit cyberattacks.

Schneider Electric; Siemens Energy; the University of California at Los Angeles (UCLA); Werum, a pharmaceutical technology provider; and AbbVie, a biopharmaceutical company, are the five latest organizations identified on the Cl0p ransomware group's Dark Web data leak site as victims of MOVEit cyberattacks.

Threat actor directory organization Falcon Feeds monitors the Cl0p ransomware leak site and released the latest list to Twitter today.

For its part, UCLA uses MOVEit Transfer to transfer files across the campus and to other entities. In a statement to Dark Reading, the university noted that it discovered the attack on May 28, after which it "immediately activated its incident response procedures, fixed the vulnerability using the security patch issued by Progress Software, and enhanced monitoring of the system."

The statement continues, "the university notified the FBI and worked with external cybersecurity experts to investigate the matter and determine what happened, what data was impacted and to whom the data belongs. Those who have been impacted have been notified. This is not a ransomware incident. There is no evidence of any impact to any other campus systems."

Last Saturday, the New York City Department of Education (DoE) revealed it was also the victim of a MOVEit cyberattack, resulting the in unauthorized access of around 19,000 documents affecting 45,000 students.

"The FBI is investigating the broader breach that has impacted hundreds of entities; we are currently cooperating with both the NYPD and FBI as they investigate," the DoE announcement of the breach said. "Given that review and investigation are ongoing, we are limited in terms of additional details at this point."  

**MOVEit File Flaw**

Progress Software's MOVEit file transfer software zero-day vulnerability was discovered May 31 and traced back to the Russian ransomware group Cl0p. But before the zero-day bug could be patched, Cl0p already had its foothold in target systems.

The ransomware group reportedly sat on the MOVEit file transfer vulnerability for two years before it started to actively target victims including the BBC, British Airways, and the government of Nova Scotia.

Subsequent MOVEit victims emerged later, including Gen Digital, parent company of Avast and Norton.

UCLA, Siemens Among Latest Victims of Relentless MOVEit Attacks

The free tool aims to help organizations meet the requirements of the new version of the payment standard, which takes effect next March.

Jscrambler has released a free tool to help companies check the JavaScript code running on their e-commerce sites and bring them into compliance with the latest PCI DSS (Payment Card Industry Data Security Standards) version 4.0.

PCI Security Standards Council released PCI DSS v4.0 in March 2022 and began a two-year phaseout of the previous versions before beginning enforcement. By March 31, 2025, all retailers and e-commerce sites – anyone who handles payment cards online, really – will need to be in compliance with these requirements. Jscrambler's PCI DSS JavaScript Compliance Tool helps organizations assess whether the JavaScript on their e-commerce sites meet to two v4.0 requirements: protection against (6.4.3) and detection (11.6.1) of skimming attacks on all scripts from a merchant or its third- and fourth-party contractors.

Section 6.4.3 requires that companies confirm that each script is authorized, ensure the integrity of the scripts, and maintain a complete inventory that explains why each script is necessary. Section 11.6.1 applies to merchants that include a third party's iframe payment form on their websites; it compels an evaluation of the HTTP header and payment page periodically (usually every seven days) that looks for and notifies the merchant about any changes to the page.

The anti-skimming requirements are necessary because attackers are launching Web skimming campaigns by injecting malicious code into Magento, WooCommerce, Shopify, and WordPress sites. Magecart skimmers have been found on 2 million websites, including those of Ticketmaster and British Airways.

The Jscrambler tool searches for and collates all scripts on a merchant's site, performing script verification and authorization, and then logging the results, including compliance status. It visualizes each script, highlighting actions that are considered suspicious, analyzes scripts for function and generates justifications for using each. Alerts are triggered if scripts are tampered with, the contents of the payment page are changed without authorization, and the HTTP header is altered. All of these functions reduce manual compliance efforts and assist in generating audit-ready reports, the company said.

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

Jscrambler Launches JavaScript Scanner for PCI DSS 4.0 Compliance

One ransomware attack can be devastating for a small or midsize business. Here are four solid survival tips to ensure it doesn't turn into a disaster.

If your organization is hit with a ransomware attack, it's going to cost you. According to Verizon's "2023 Data Breach Investigations Report"(DBIR), released earlier this month, the median loss to a ransomware attack has risen to $26,000 and can go as high as $2.25 million.

"\[T\]he overall costs of recovering from a ransomware incident are increasing, even as the ransom amounts are lower. This fact could be suggesting that the overall company size of ransomware victims is trending down," the DBIR team wrote.

Much of the expense comes from the loss of business and recovery time. The average ransomware attack has a life cycle of more than 300 days. That's nearly a full year in which the organization is tied up with discovery and remediation — and almost two months longer than other types of cyber incidents. And then there are other costs to factor, such as long-term damage to the corporate brand and reputation, as well as loss of institutional knowledge when the employees who are held responsible for the attack are let go.

The costs surrounding a ransomware attack could cripple small and midsize businesses (SMBs) and even cause one to shut down. But it doesn’t have to be that way. Even for SMBs with tight IT/security budgets and limited security expertise, ransomware protection and recovery boils down to planning ahead.

The best way to avoid the high costs of a ransomware attack is to avoid being a victim, but protection and detection tools also come with hefty price tags. How much a company will need to pay depends on the number of employees and devices it needs to protect, but even a company with as few as 50 people can spend five figures on ransomware protection. Cyber insurance to protect the business in case of an attack could add at least $1,500 per $1 million in coverage, depending on the deductible.

Note that getting cyber insurance for ransomware is not easy; many insurance agencies are limiting coverage because of the high payout costs.

Organizations also need to think about the cybersecurity approach they want to take. How cybersecurity teams approach ransomware defense has changed over the years, says PJ Kirner, CTO and co-founder of Illumio. Cybersecurity has shifted from perimeter defense (setting up a secure perimeter to keep the bad guys out), to rapid detection (detecting and stopping as quickly as possible), to containment (limiting the amount of damage the attackers can cause once they break in).

Which approach an SMB decides to take determines the type of tools and protective actions it will need. A company deciding to contain malware would make investments to beef up authentication and privilege management in order to validate all users and devices before granting access to any transaction. A company focused on perimeter defense would have very different investments, requiring firewalls and other methods to keep attackers out of the network.

While an organization can adopt any number of security systems and tools, SMBs should consider the following actions, regardless of their overall security approach.

**1\. Decrease the Attack Surface**

Applying the concept of least-privilege access can close the door against ransomware attacks. The fewer people with access to applications and databases, the lower the chances for cybercriminals to also gain access and get in. Audit your users' roles to make sure they have access only to the software and services they need, especially if the software processes sensitive data.

For example, explains Kirner, Remote Desktop Protocol (RDP) is a popular access point for threat actors to get into a Windows system and launch ransomware. But RDP is most often used for IT help desks and troubleshooting. Most employees across the business have no need to have RDP accounts, yet they might have RDP enabled on their machines. Kirner advises revoking access if employees have no reason to have those accounts.

"Remove all that attack surface from your environment," Kirner says. "This is something you can do proactively and reduce the impact of ransomware."

Also worth disabling — especially in a Windows environment — is PowerShell. Attackers are increasingly using PowerShell in malware-less attacks. The average user is never going to use it, so it's better to disable it when setting up the user machine. Similarly, keep track of what accounts have been created on the network or for cloud applications and services. If the employee no longer needs it or has left the company, remove that account entirely. Cloud access security broker software can help manage and monitor employees’ cloud activity and enforce security policies.

**2\. Shift the Costs to the Attackers**

Another way to make your organization less attractive to bad actors is to make launching an attack more costly for the cybercriminal. Something as simple as restricting access to unnecessary applications shifts the burden to the attacker. If the attacker can’t do much with the application despite having user credentials — maybe they can only view reports but can’t extract data — the attacker has a choice of moving on to easier victims or working harder. Similarly, requiring multifactor authentication adds another roadblock for threat actors because just stealing credentials is no longer enough. Many types of MFA can fit an SMB's budget and security expertise, including biometrics, hardware tokens, and even the employee’s phone.

Attackers are economic actors, just like any other business, Kirner points out. "When they run out of time, they'll go to an environment with less security controls," he says.

**3\. Improve Your Security Hygiene**

Good security hygiene is important, regardless of company size.

The first step is to build an internal security culture around cybersecurity awareness and guidance, explains Dave Gerry, CEO at Bugcrowd. That doesn’t just mean watching security videos and calling it a day. Encourage open communications and give employees the confidence to report anything that seems suspicious.

Explain which external services and resources are allowed and why there are restrictions. Make it easy for employees to go through an approval process for getting access to tools so that they aren’t just going off and creating their own accounts.

Use modern training materials. Security companies are now producing training videos that are episodic, like sitcoms, or use techniques from reality shows that entertain as well as educate.

Gamification, such as setting up contests or offering rewards when designated milestones are met, also creates an environment where employees want to improve their security practices. Human error is a top cause of cyberattacks. When employees are encouraged to take an active role in cybersecurity and understand the consequences when they don't, you add another cybersecurity tool at little cost.

**4\. Don't Fail to Plan**

Prevention is important, but every organization should have a plan in place to mitigate an attack when it happens. The company should know who will be involved in mitigation and recovery, as well as how to handle the negotiations.

For example, because of the possibility that a ransomware attack can lead to permanently shutting down an SMB, many plan to pay the ransom. That requires setting a budget on how much to pay. If the organization does not already have a cryptocurrency wallet or access to cryptocurrency, that will make payment a bit difficult. SMBs are already working with managed service providers, consultants, and contractors. It may be worth lining up a ransomware negotiator ahead of time, who can spring into action when needed. The same goes for a computer forensics team to help figure out what is happening on the network and how to remove the ransomware.

Priority No. 1 has to be a strategy, says Joseph Carson, chief security scientist at Delinea. A ransomware attack isn't a typical incident, he points out. It will make you unavailable to your customers and, in worst-case scenarios, put lives at risk. No matter how small your budget, it is essential to think about what ransomware defense should look like but to also plan out what is needed for a successful recovery.

Protecting Small Businesses From Ransomware on a Budget

Cequence's latest updates to its Unified API Protection platform help organizations reduce the time needed to create API security testing plans.

API security company Cequence Security has updated its API protection platform with generative AI and no-code security automation to help organizations with security testing and reporting, the company said.

IDC estimates that up to 50% of enterprises’ revenues are enabled over application programming interfaces (APIs), making API security a top priority for CISOs, stated Cequence Security in a blog post about the new capabilities. With generative AI, security teams working with Cequence’s Unified API Protection (UAP) platform can generate API Security Test Plans using plain English, the company said. UAP's Intelligent Mode automatically associates the appropriate APIs with the right test cases, given the functionality of that API.

Cequence gave an example in its blog: Security analysts can say, “Generate a test plan for my Payments API to ensure PCI data compliance,” and the platform will automatically inspect the Payment API endpoints and the payload characteristics to associate the appropriate test cases that would verify that the endpoints are performing as expected.

This functionality reduces the time needed to create a test plan to minutes, rather than months, according to the company.

Security analysts can also use low-code/no-code tools within Cequence to link together multiple third-party connections to implement the equivalent of an API security orchestration and response workflow, the company said. It provided an example of how analysts can create a workflow to log a JIRA ticket when sensitive data exposure is detected from a shadow API, automatically geofence access to the API to internal applications only, and then send an email to the relevant developer or business owner alerting them to the issue.

Other updates to the platform include adding new test cases for the latest OWASP API Top 10 2023 to the test catalog and the ability to run API tests outside of CI/CD pipelines and test directly against staging and production servers.

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

Cequence Security Adds Generative AI to API Security

By leveraging misconfigured DLLs instead of EDR-monitored APIs, this new technique injects malicious code into running processes, completely evading endpoint security.

Endpoint detection and response (EDR) systems have become increasingly efficient at detecting typical process injection attempts that invoke a combination of application programming interfaces to insert code into the memory space of a running process.

So researchers at Israeli-based Security Joes set out to find another way to due process injection without relying on EDR-monitored APIs. The result is Mockingjay, a novel method for process injection that leverages dynamic link libraries (DLLs) with default read, write, and execute (RWX) permissions to push code into the address space of a running process.

**The Mockingjay Approach**

The approach reduces the likelihood of an endpoint security mechanism detecting a malicious process injection effort and requires a smaller number of steps to achieve, Security Joes said in a report this week. "Our research aimed to discover alternative methods to dynamically execute code within the memory space of Windows processes, without relying on the monitored Windows APIs," the security firm said.

"Our unique approach, which involves leveraging a vulnerable DLL and copying code to the appropriate section, allowed us to inject code without memory allocation, permission setting, or even starting a thread in the targeted process."

Process injection is a technique for manipulating the memory of a process to either add new functionality or modify its behavior. Attackers commonly use the method to hide malicious code and evade detection on compromised systems. Common process injection methods include self-injection where a process that receives the injected payload also executes it; DLL injection where a malicious DLL is loaded into the memory space of a process; and PE injection where a portable executable file is mapped into the memory of a running process.

"Each of these injection techniques requires a set of specific Windows APIs, which generate characteristic patterns that can be leveraged by defenders and security software for detection and mitigation purposes," Security Joes said in its report. For instance, the APIs required for self-injection are VirtualAlloc, LocalAlloc, GlobalAlloc, and Virtual Protect, the company said. Similarly, the APIs used in PE injection are VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread. Most EDR systems are tuned to monitor commonly used APIs in process injection attacks and can effectively identify malicious activity associated with their use.

**Abusing Vulnerable DLLs**

The strategy Security Joes used in developing Mockingjay was to systematically search for DLLs within the Windows OS that contained a default RWX section. Researchers at the company developed a tool that explored the entire Windows file system to identify DLLs that could serve as potential vehicles for code injection without triggering an EDR alert. The exploration resulted in Security Joes finding a DLL (msys-2.0.dll) with 16KB of RWX space in Visual Studio 2022 Community that they could use for injecting and executing their own code.

"After identifying the vulnerable DLL that contains a default Read-Write-Execute (RWX) section on disk, we conducted several tests to explore two different methods that could leverage this misconfiguration to execute code in memory," Security Joes said.

One method was to directly load the vulnerable DLL into the memory space of a custom application called nightmare.exe that Security Joes developed. Doing that allowed researchers to inject and execute their own shellcode into the memory space of the application without leveraging any Windows APIs. Among other things, the shellcode also removed all EDR hooks without triggering any alerts. "This complete removal of dependency on Windows APIs not only reduces the likelihood of detection but also enhances the effectiveness of the technique," the company said.

Security Joes' second tactic for abusing the RWX section in the DLL was to do process injection in a remote process. To achieve this, they first identified binaries that used mysys-2.0.dll for their operations. Many of these were associated with GNU utilities and other applications that require POSIX emulation. For the proof-of-concept, researchers chose the ssh.exe process in Visual Studio 2022 Community as the target for injecting their code. "It is important to note that in this injection method, there is no need to explicitly create a thread within the target process, as the process automatically executes the injected code," the company explained.

According to Security Joes, the DLL that its researchers used to developed Mockingjay is just one of potentially many others that can similarly be abused for code injection purposes. Addressing the threat requires endpoint security tools that don't just monitor specific APIs and DLLs but also use behavioral analysis and machine learning techniques to identify process injection.

Source

DARKReading