About RPrasadi

By Yaron Avital, Senior Staff Researcher    GitHub Actions, for good reason, is the go-to choice for countless developers. Despite its convenience, though, potential security risks accompany third-party actions. In this post, we share how the world’s most popular repositories fail to manage their build permissions and walk you through   the why   and   the how   of proper permissions management in GitHub Actions.   GitHub Actions has gained immense popularity in recent years as a powerful and flexible automation platform for software development workflows. With its intuitive user interface, extensive library of prebuilt actions and seamless integration with GitHub repositories, it has become a go-to choice for many developers and organizations seeking to streamline their CI/CD pipelines, automate routine tasks, and improve collaboration across teams.   But convenience and accelerated development aside, using third-party actions comes with security risks. GitHub cautions organizations by plainly stating, "There is significant risk in sourcing actions from third-party repositories on GitHub." The statement underscores the importance of ensuring the security of workflows on the platform.   In this blog post, we cover the all-important reasons AppSec engineers need to properly manage permissions in GitHub Actions — while also showing how the vast majority of GitHub organizations fail to correctly handle these permissions.   Action’s Permissions   When a workflow runs, GitHub issues a short-lived GITHUB_TOKEN for the workflow to interact with the repository. This token has since become a target for attackers who succeed in executing code in a workflow, as it provides them with the same level of permission as the token. Command injection in the CI, compromised dependencies or actions — all allow attackers to access the token and use it against the repository.   Tokens in each workflow are set by the repository administrators and maintainers with read or write access to a list of scopes. If not specifically set in the workflow configuration file, the default setting of the repository will determine permissions. In February 2023, applicable to new organizations, GitHub changed the default permissions granted to this token from “write-all”, granting write permissions on all available scopes, to read-only for the contents, packages and metadata scopes.   Developers who want to limit the permissions to the minimum can explicitly grant permissions to each workflow or a job, which is a smart move. Know the caveats, though. GitHub Actions supports the "write-all" and “read-all” scopes, granting all permissions. Also, even if granular permissions are set, they should match against the permissions the action requires to fulfill its purpose.   Let’s review why it’s a bad practice to allow broader scopes than required.   Permissions Worth Taking a Closer Look   Granting higher permissions to workflows that aren’t required, like “write-all”, “read-all” or actions in figure 1, fuels post exploitation techniques and allows attackers to inflict serious damage to the organization.   Figure 1: Actions commonly granted overly permissive actions can result in damaging exploitation.     Granting Tailored Permissions   GitHub allows setting granular permissions per a workflow’s job, and we can use an action inside a job, isolated from the rest of the workflow.   Let’s grant the third-party action the exact permissions it needs to operate.   Unlike the installation of GitHub apps where you authorize each permission used by the app beforehand, when making use of a GitHub action, there’s no permissions approval process. What’s more, there’s no central location, GitHub or otherwise, to find what permissions a third-party action requires. This makes it difficult for developers to maintain the important principle of   least privilege. From good will, the maintainers occasionally mention the recommended permissions, like in   actions/stale. But this isn’t enforced or standardized by GitHub, and in general, it’s rare to see guidelines on required permissions provided by maintainers.    Figure 2: The Close Stale Issues action by GitHub provides recommended permissions. [Source]   Creating Action Permissions Database   We’ve created PiPER (a portmanteau of pipeline and permissions), an internal tool that calculates the minimal required permissions for a given action. It works by performing static code analysis on the actions’ code, identifying any action made against the repository, and mapping usage to a permission. Achieving good coverage isn’t so straightforward, as the GitHub API can be accessed in various ways, such as interacting with it directly through HTTP or by using various libraries that wrap it. Additionally, both the REST API and the GraphQL endpoints can be used.   We used PiPER to analyze the top 1000 popular actions on the GitHub marketplace.   We've learned that about 50% of the actions don’t perform any interaction against the repository and, therefore, don’t require the GitHub token to fulfill its purpose.   Figure 3: Fifty percent of the analyzed actions require no permission.     In fact, 94% of actions require only 2-3 of the 13 available scopes — contents, issues and pull-requests being the popular ones. For example, the   rtCamp/action-slack-notify   action doesn't have any interaction with the GitHub API, so the GitHub token accessible by this action shouldn’t be granted permissions against the repository. You can achieve this by explicitly declaring it inside the job/workflow, as follows:   Figure 4: Disable permissions for all the available scopes.     How Major Projects Manage Permissions   We began to wonder how popular open-source projects manage their workflows’ permissions. Do they limit each action to the minimum required?  Do they manage cases where several actions are used in one workflow and each requires a different level of permissions?   To answer these questions, we created a list of the top starred 2000 public projects on GitHub using GitHub actions. As workflows triggered by pull requests originating from forks are set with read-only permissions by default, we analyzed build logs triggered by “push” events, extracted the third-party actions in use in each workflow, and calculated their effective permissions against the repository.   We now have the following:   Database of actions and their required permissions, created by PiPER List of workflows used by the top 2,000 GitHub public repositories using GitHub Actions, as well as the third-party actions they use and their permissions granted through the GitHub token.   We learned that the top 2,000 repositories are configured with approximately 6,000 workflows, all of which use 1,045 unique actions. Key observations we made include:   1. A staggering 93% of the 2,000 GitHub repositories that use GitHub Actions have at least one overly permissive workflow.   Figure 5: 93% of the analyzed repositories have at least one workflow with excessive permissions, as calculated by comparing granted permissions to required permissions using PiPER.   2. The vast majority of the open-source projects, 80%, doesn’t specify permissions in their workflow yaml, leaving the problematic default permissions in effect. That’s a lot of projects! But, most of them probably set minimal default permissions in the repository level, right? Well, far from it — 86% of the projects that didn’t specify permissions in their workflows were found overly permissive. 3. What happens when the repository maintainers do set granular permissions? In 36% of the open-source projects that invested time limiting the permissions of their GitHub token, their workflows were still overly permissive. It happens because permissions granted don’t match the actions’ requirements, or they’re specified for the entire workflow and not tailored per each job’s requirements.   Major Projects Using Low-Reputation Actions   Additionally, we encountered many cases where low-reputation actions with a low number of stars and forks maintained by private users — not having a GitHub “Verified Creator” badge, GitHub own vetting process — are effectively granted write-all permissions. As we can see in the following examples, first by taking a peak in the build logs, this is how we can tell the effective permissions of a job is “write-all”:   Figure 6: The effective permissions of a job are printed to the build logs when it starts.     A few examples of low-reputation actions used by workflows of highly popular GitHub repositories — unpinned and granted with highly excessive permissions to the repository through the GitHub token — include   re-actors/alls-green   used by   Microsoft   and   FastAPI,   bwoodsend/setup-winlibs-action   used by   Cloudflare, and   ljharb/actions   used by   Airbnb. This is a serious security risk. Any action compromised could potentially be used to attack your GitHub organization all the way to the production environment.   Remediation   GitHub Actions is a powerful tool that can help developers automate their workflows. But it’s important to stay on top of the security risks associated with using this tool.   Attackers could leverage a malicious action to compromise a repository. To mitigate this risk, use job isolation, running each job in a separate container. Then, if one job is compromised, the others won’t be affected.   Another important security measure is to use tailored permissions, meaning to grant only the permissions necessary for an action to complete its task. For example, if an action needs to access pull requests, it should only be granted the pull-request:read permission. Implementing job isolation and splitting third-party actions into separate jobs opens up the option to grant tailored permissions, which reduces granted permissions and mitigates the security risks associated with using GitHub Actions. It’s important to remember, though, that no security measure is perfect. You must remain vigilant and continuously evaluate the security of workflows to protect against potential security breaches.   Figure 7: Workflow with excessive permissions     Figure 8: Breaking down the workflow to separate jobs with granular permissions for each job   Additional Tips for Securing GitHub Actions Workflows   Use actions listed on the GitHub Marketplace that have the "verified creator" badge. Prefer known vendors you can trust over unknown actions maintained by private developers. Conduct a vetting process that includes reviewing the code of the third-party action and set the permissions accordingly. Pin actions to full commit hashes. This ensures that you always use a known-good version of an action, even if an attacker compromises an action and makes changes to the code.   By following these practices, you can help to protect your organization from the security risks associated with GitHub Actions workflow permissions.   Learn More   If you’re interested in learning practical tips to get started with CI/CD security, read the   CI/CD Security Checklist. You’ll find six best practices to help you embrace CI/CD security and harden your pipelines over time. ... View more

By Jonathan Bregman,  Senior Product Marketing Manager     With the rise in attacks on continuous integration and continuous delivery (CI/CD) environments, it’s no surprise that the U.S. Government recently   released guidance   to help organizations understand their risks and defend their pipelines. CI/CD pipelines are critical to cloud-native software development and host highly sensitive data and credentials. But they often exist outside the purview of traditional AppSec teams. To help AppSec practitioners secure their pipelines, we’re excited to announce CI/CD Security by Prisma Cloud. With   graph-based CI/CD security   in the industry’s most comprehensive code-to-cloud cloud-native application protection platform (CNAPP), Prisma Cloud gives you:   Unmatched visibility into your engineering ecosystem Protection from the OWASP Top 10 CI/CD Risks Pipeline Posture Management Attack Path Analysis via the Cloud Application Graph™   Let’s dive into the details.   Unmatched Visibility into the Engineering Ecosystem   As developers commit code to source control, most organizations have deployed various types of code scanners to detect misconfigurations in templates, vulnerabilities in open-source packages, exposed secrets and other issues. The best tools provide granular fix guidance directly for developers, but given the diversity of code and supporting scanners,   AppSec   teams are left with a fragmented view of risk spread across multiple siloed tools. What’s more, most organizations lack visibility into developers contributing to trusted artifact registries, which technologies and frameworks are in use, and how to export a   software bill of materials (SBOM)   of the environment. Prisma Cloud’s new Application Security dashboard unifies visibility across the engineering ecosystem. From a single pane, AppSec teams gain visibility across code repositories, contributors, technologies used and pipelines connected, along with specific code risks. By understanding which repositories and pipelines connect to production, teams can easily prioritize risk with full infrastructure context.   Figure 1: The Application Security dashboard provides a centralized view of your entire engineering ecosystem _palo-alto-networks .     Defending Against the OWASP Top 10 CI/CD Risks   ]Attacks that seek to   breach delivery pipelines   are far too common, and up until recently no industry-recognized framework was available. To provide guidance on attack vectors and best practices to mitigate them, Prisma Cloud’s world-class AppSec researchers developed and published a formally recognized industry benchmark — the   OWASP Top 10 CI/CD Security Risks   project. Organizations can benefit from the project at any stage in their CI/CD security journey. For example, it’s easy for teams to use the project’s guidance to help identify misconfigurations for version control systems (VCS) and   CI/CD pipelines. Those misconfigurations could easily lead to code tampering, credential theft and ultimately a runtime breach.     Figure 2: The OWASP Top 10 CI/CD Security Risks_palo-alto-networks     Pipeline Posture Management   To embrace   DevSecOps, it’s essential to observe the posture of your delivery pipeline, ensure it’s protected against the Top 10 CI/CD risks and then report your findings to leadership. Prisma Cloud’s new dashboard provides continuous visibility across the critical pipeline issues with added context like system risks and both the number and frequency of events to accurately measure and alert on criticality.   Figure 3: Prisma Cloud provides continuous pipeline posture management against the OWASP Top 10 CI/CD Risks_palo-alto-networks   Attack Path Analysis via the Cloud Application Graph™   The power that   graph databases   bring to contextualizing security insights can’t be overstated. The ability to correlate multiple risk signals simultaneously to map an attacker's pathway to a breach is critical to delivering high fidelity alerts for AppSec teams. The Prisma Cloud Application Graph™ provides a dynamic visualization of your engineering ecosystem that allows you to better understand and analyze the environment and relationships between all artifacts from code to deployment. By effectively modeling every asset, you can map attack paths. This is critical as you protect your delivery pipelines from today’s sophisticated attacks. For example, cross-platform misconfigurations like   poisoned pipeline execution (PPE)   are only discoverable with graph-based analysis, which is why Prisma Cloud’s CI/CD Security is built off of the world’s first Application Graph.   Figure 4: The Prisma Cloud Application Graph™ helps customers uncover breach paths _palo-alto-networks .     CI/CD Security and AppSec: Looking to the Future   In this modern threat landscape,   protecting the delivery pipeline   is more important than ever. Going forward, security and risk leaders must prioritize hardening CI/CD systems and processes as they begin to   rearchitect their AppSec programs   to account for the evolving threat landscape. Since its inception, Prisma Cloud has been at the forefront of delivering solutions for the most pressing cloud security challenges. With the industry’s only code-to-cloud CNAPP, customers can now protect their delivery pipeline with graph-based CI/CD security. To watch a live demo of CI/CD Security by Prisma Cloud, visit us at booth #1332 at BlackHat USA 2023. We’ll also highlight our research with related talks at BSidesLV and DEFCON this year:   Actions Have Consequences: The Overlooked Security Risks in Third-Party GitHub Actions Wednesday, August 9 at 2:30pm PDT,   BSidesLV The GitHub Actions Worm: Compromising GitHub Repositories Through the Actions Dependency Tree Tuesday, August 8 at 5:00pm PDT,   BSidesLV Saturday, August 12 at 1:30pm PDT,   DEFCON   And if you want to learn which attack vectors you should prioritize at the start of your CI/CD security journey, read this technical guide on the   Top 10 CI/CD Security Risks. ... View more

In this session we will discuss what the top trends are in cloud security and how breach response looks like in the current cloud landscape. What are the actions a company should take ahead of time, and what issues arise after a breach occurs. This talk will also focus on vulnerability MGMT, and the best practices for avoiding incidents. ... View more

By William Gamazo,  Principal Researcher and Nathaniel Quist, Manager   Executive Summary   On July 11, 2023, Unit 42 cloud researchers discovered a new peer-to-peer (P2P) worm we call P2PInfect. Written in Rust, a highly scalable and cloud-friendly programming language, this worm is capable of cross-platform infections and targets Redis, a popular open-source database application that is heavily used within cloud environments. Redis instances can be run on both Linux and Windows operating systems. Unit 42 researchers have identified over 307,000 unique Redis systems communicating publicly over the last two weeks, of which 934 may be vulnerable to this P2P worm variant. While not all of the 307,000 Redis instances will be vulnerable, the worm will still target these systems and attempt the compromise.   The P2PInfect worm infects vulnerable Redis instances by exploiting the Lua sandbox escape vulnerability,   CVE-2022-0543. While the vulnerability was disclosed in 2022, its scope is not fully known at this point. However, it is rated in the NIST National Vulnerability Database with a Critical CVSS score of 10.0. Additionally, the fact that P2PInfect exploits Redis servers running on both Linux and Windows operating systems makes it more scalable and potent than other worms. The P2P worm observed by Unit 42 researchers serves as an example of a serious attack threat actors could conduct using this vulnerability.   P2PInfect exploits CVE-2022-0543 for initial access and then drops an initial payload that establishes P2P communication to a larger P2P network. Once the P2P connection is established, the worm pulls down additional malicious binaries such as OS-specific scripts and scanning software. The infected instance then joins the P2P network to provide access to the other payloads to future compromised Redis instances.   Exploiting CVE-2022-0543 in this way makes the P2PInfect worm more effective at operating and propagating in cloud container environments. This is where Unit 42 researchers discovered the worm by it compromising a Redis container instance within our HoneyCloud environment, which is a set of honeypots that we use to identify and study novel cloud-based attacks across public cloud environments.   Unit 42 believes this P2PInfect campaign is the first stage of a potentially more capable attack that leverages this robust P2P command and control (C2) network. There are instances of the word “miner” within the malicious toolkit of P2PInfect. However, researchers did not find any definitive evidence that cryptomining operations ever occurred. Additionally, the P2P network appears to possess multiple C2 features such as “Auto-updating” that would allow the controllers of the P2P network to push new payloads into the network that could alter and enhance the performance of any of the malicious operations. Unit 42 researchers will continue to monitor for changes and update accordingly.   Palo Alto Networks customers receive protections against the types of threats discussed in this article through products including:   Prisma Cloud Advanced WildFire Cloud-Delivered Security Services   for the   Next-Generation Firewall, including   Advanced URL Filtering   and   Advanced Threat Prevention.   If you believe you have been compromised by P2PInfect, the   Unit 42 Incident Response team   can provide a personalized response.   Self-replicating Peer-to-Peer Worm   Unit 42 discovered the first known instance of P2PInfect on July 11, 2023, using our HoneyCloud environment, which is a set of honeypots that we use to identify and study novel cloud-based attacks across public cloud environments.   The P2PInfect worm uses a P2P network to support and facilitate the transmission of malicious binaries. We chose the name because the term P2PInfect appears in the leaked symbols reflecting the malware author project structure, as shown in Figure 1.      Figure 1. Artifacts of the Windows version, names and Redis module_palo-alto-networks.   All collected samples of the P2P worm are written in Rust, a highly scalable and cloud-friendly programming language. This allows the worm to be capable of cross-platform infections that target Redis instances on both Linux and Windows operating systems (please note that Redis does not officially support the Windows OS).   The worm infects vulnerable Redis instances using the Lua sandbox escape vulnerability,   CVE-2022-0543. The first exploit for this particular vulnerability was published in March 2022, which resulted in the connection of the infected Redis instance to the   Muhstik botnet. However, the P2PInfect worm appears to be associated with a different malicious network, not known to be related to the Muhstik botnet.   After initial infection through the exploitation of the Lua vulnerability, an initial payload is executed that establishes a P2P communication to the larger C2 botnet, which serves as a P2P network for delivering other payloads to future compromised Redis instances. Once the P2P connection is established, the worm pulls down additional payloads, such as a scanner. The newly infected instance then joins the ranks of the P2P network to provide scanning payloads to future compromised Redis instances. Exploiting CVE-2022-0543 makes P2PInfect effective in cloud container environments. Containers have a reduced set of functionalities – for example, they do not have “cron” services. Many of the most active worms exploiting Redis use a technique to achieve remote code execution (RCE) using cron services. This technique does not work in containers. P2PInfect incorporates the exploit for   CVE-2022-0543   with the intention of covering as many vulnerable scenarios as possible, including cloud container environments.   The following sections will cover details about the   exploitation payloads, the   behavior of P2PInfect, and some of the details of the   P2P network protocol.   Since the P2PInfect worm is newly discovered, we have focused here on providing an overview of its behavior and the P2P architecture it supports, as well as basic sample analysis. However, additional analysis and study is warranted in future research.   Exploitation of CVE-2022-0543   P2PInfect currently exploits the Lua sandbox escape vulnerability CVE-2022-0543 for initial access. This vulnerability has been used in previous attacks such as   Muhstik   and   Redigo, both of which resulted in the compromised Redis instances participating in denial-of-service (DoS), flooding and brute-forcing attacks against other systems.   This exploit vector follows a similar pattern to what has been seen previously. However, the post-exploit operations of P2PInfect are significantly different from the previous uses of the vulnerability. It is important to note that this vulnerability is not a Redis application vulnerability — it is specifically a Lua sandbox vulnerability.   While this campaign does target vulnerable Redis instances and perform worm-like operations, there are no known links to other threat actor groups known for targeting Redis and deploying worms, such as   Automated Libra (aka PurpleUrchin),   Adept Libra (aka TeamTNT),   Thief Libra (aka WatchDog),   Money Libra (aka Kinsing),   Aged Libra (aka Rocke)   or   Returned Libra (aka 8220).   How P2PInfect Leverages CVE-2022-0543 to Infect Vulnerable Redis Instances   The P2PInfect worm’s initial infection vector – exploiting Redis through CVE-2022-0543 – is not common among other cryptojacking-focused worms known to target Redis instances, such as those created by Adept Libra (aka TeamTnT), Thief Libra (aka WatchDog) threat actors or the ones delivering Money Libra (aka Kinsing) variants. These groups use alternative Redis vulnerabilities or misconfigurations in order to operate.   CVE-2022-0543   is a vulnerability with the Lua library related to the way Redis is packaged and delivered by Debian Linux package management. A s such, it only affects users of Redis who use the Debian or derived (Ubuntu and others) distributions . Due to the focus on the OS and leveraging a subcomponent of Redis to compromise, P2PInfect’s exploitation efforts are therefore complex. Figure 2 shows an example of a captured exploit for CVE-2022-0543.     Figure 2. Example of the P2PInfect exploit on the Debian OS _palo-alto-networks.   .     Within the above image, one can see how the vulnerability is being weaponized. By using network requests through   /dev/tcp , as seen on line four, the threat actor connects to a C2 IP address, written as   ip-cnc   over port 60100. Port 60100 is one of the P2P communication ports used by P2PInfect to maintain C2 communication. The initial payload, also seen on line four, sets the   GET   request to the directory   /linux , which is the main dropper maintaining the core functionality of the P2PInfect worm. Other binaries are distributed within the P2P network, as we are going to see later in the article.   Network Communication Behavior   P2PInfect uses its P2P network to distribute follow-up malware to newly infected systems or cloud instances. When a system is first compromised, it will make a network connection to the P2P network and download the samples for the custom protocol to be used. As Figure 3 illustrates, the command:   GET /linux , is followed by the image download of the core P2PInfect functionality.     Figure 3. Network communication protocol displaying the download of P2PInfect. Both Linux and Windows OS P2PInfect samples communicate in the same manner. The following samples were downloaded from the P2P network in plaintext:   linux ,   miner ,   winminer   and   windows   (see Figure 4).     Figure 4. List of the malware samples pulled from the P2P network _palo-alto-networks.      .   Once the core P2PInfect sample finishes execution, the payload will start scanning for additional hosts to compromise. The scanning operation focuses on exposed Redis hosts. However, researchers also found that compromised Redis instances also perform scanning attempts over port 22, SSH. While it is not clear why this scanning operation is taking place, as there are no known exploitation attempts by P2PInfect to compromise SSH, it is not altogether uncommon for port 22 to be scanned post-compromise by other known worms. Please see the   Scanning Behavior   section for additional details.   Node Communications   The main dropper communicates with any other listening P2P members on the current list of configured nodes using TLS 1.3. The C2 infrastructure is updated when the compromised node sends a json request with all known nodes to the P2P network. Updates to the C2 infrastructure will automatically be downloaded. The following image, Figure 5, shows an example of the nodes update.     Figure 5. P2P nodes update _palo-alto-networks.     The values with   x.x.x.x   are the current node IP, or the new learned nodes.   Scanning Behavior   Figure 6 illustrates the network scanning behavior of an infected host scanning for exposed SSH instances. These scanning operations occur across a random netrange selected by the P2PInfect functionality. Figure 6. Scanning traffic for SSH instances _palo-alto-networks.   . Figure 7 illustrates the P2PInfect scanning operations for exposed Redis instances.     Figure 7. Scanning traffic for Redis instances _palo-alto-networks.     Other Observations of P2PInfect   Some of the initial payload P2PInfect samples deliver ed to exploited systems were packed with UPX, while the second-stage malware samples,   miner   and   winminer , were not UPX packed.   After the first dropper runs, it starts decrypting the configuration received from a command line, with information about other nodes in the P2P network. We found that the P2P port was variable – a design choice that allows the attack to be resilient to blocking and network firewall mitigation techniques (see Figure 8).     Figure 8. Example of the variable port usage of P2PInfect _palo-alto-networks.   All samples identified by Unit 42 researchers have been written in Rust, and some have “symbols leaked” inside, which gives indicators about the malware authors’ project structure. For example, the   windows   sample main execution thread leaks the name of the project as well as the file directory usage of the threat actor (see Figure 9).     Figure 9. Analysis pulled from the core Windows P2PInfect sample _palo-alto-networks.   We also identified a PowerShell script designed to establish and maintain communication between the compromised host and the P2P network. The PowerShell script leveraged the   encode   command to obfuscate the communication initiation (see Figure 10).     Figure 10. Obfuscated PowerShell command to establish P2P network connection _palo-alto-networks.   One of the first operations performed by the PowerShell command is to configure the local system firewall to block legitimate access to or from the compromised Redis application (see line five of Figure 11). Then (starting on line 17 in Figure 11), the script opens a communication port for the threat actor to access the compromised instance. This is a form of persistence, allowing the threat actors to maintain access to the infected host and keep it operable.       Figure 11. Modifying the network traffic rules of a compromised Windows instance _palo-alto-networks.     Of note from the decoded PowerShell, shown in Figure 11, are the following firewall configuration settings: Peer-to-peer port is 60102 – this port is variable, as not all nodes use the same port Redis port 6379 is only allowed to connect known C2 IPs The firewall rule is named   Microsoft Sync   The Monitor Process   Another interesting feature of the initial P2PInfect payload when running in Windows OS is a process called the   Monitor . The Monitor process fulfills the role of maintaining the functionality of the P2PInfect running processes on the infected host. The Monitor is dumped to   C:\Users\username\AppData\Local\Temp\cmd.exe   (see Figure 12 for an example of the Monitor ( cmd.exe ) enumerating system running processes).     Figure 12. The P2PInfect Monitor sample,   cmd.exe   process tree _palo-alto-networks.   After launching the Monitor ( cmd.exe ), the initial P2PInfect payload downloads new versions of itself from the P2P network and persists them with random names into the same original folder and an encrypted configuration is dropped ( .conf ) (see Figure 13).     Figure 13. Example of the random file names _palo-alto-networks.     The new P2PInfect download versions are executed, and the scanning operations to locate additional vulnerable Redis instances starts. The initial P2PInfect dropper will attempt to delete itself (see Figure 14).     Figure 14. Deletion of the core P2PInfect payload _palo-alto-networks.       Conclusion   The P2PInfect worm appears to be well designed with several modern development choices. Key among these is the use of the Rust language, which provides resilient capabilities and the flexibility to allow the worm to rapidly spread across multiple operating systems.   The design and building of a P2P network to perform the auto-propagation of malware is not something commonly seen within the cloud targeting or cryptojacking threat landscape. At the same time, we believe it was purpose-built to compromise and support as many Redis vulnerable instances as possible across multiple platforms.   We have caught several samples within our HoneyCloud platform, across multiple geographic regions, and we strongly believe the number of P2P nodes is growing. This is due to the volume of potential targets – over 307,000 Redis instances communicating publicly over the last two weeks – and since the worm was able to compromise multiple of our Redis honeypots across disparate regions. However, we don't have an estimate yet of how many nodes exist or how fast the malicious network associated with P2PInfect is growing.   We recommend that organizations monitor all Redis applications, both on-premises and within cloud environments, to ensure they do not contain random filenames within the   /tmp   directory. Additionally, DevOps personnel should continually monitor their Redis instances to ensure they maintain legitimate operations and maintain network access. All Redis instances should also be updated to their latest versions or anything newer than redis/5:6.0.16-1+deb11u2, redis/5:5.0.14-1+deb10u2, redis/5:6.0.16-2 and redis/5:7.0~rc2-2.   Palo Alto Networks customers receive protections against the types of threats in the following ways:   Prisma Cloud   is capable of identifying the runtime environment of any cloud Redis instance to ensure it detects and prevents the unknown and malicious execution of the P2PInfect worm. Cloud-Delivered Security Services   for the   Next-Generation Firewall include a variety of protections. Advanced URL Filtering   blocks malicious IoCs related to this worm. Advanced Threat Prevention   can block the attacks with Best Practices via Threat Prevention signatures   92349   and   93004. The   Advanced WildFire   cloud-delivered malware analysis service accurately identifies known samples as malicious.   If you think you might have been impacted or have an urgent matter, get in touch with the   Unit 42 Incident Response team   or call:   North America Toll-Free: 866.486.4842 (866.4.UNIT42) EMEA: +31.20.299.3130 APAC: +65.6983.8730 Japan: +81.50.1790.0200   Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the   Cyber Threat Alliance.   Indicators of Compromise   SHA256 Samples   Linux: 88601359222a47671ea6f010a670a35347214d8592bceaf9d2e8d1b303fe26d7 Miner: b1fab9d92a29ca7e8c0b0c4c45f759adf69b7387da9aebb1d1e90ea9ab7de76c Windows: 68eaccf15a96fdc9a4961daffec5e42878b5924c3c72d6e7d7a9b143ba2bbfa9 WinMiner: 89be7d1d2526c22f127c9351c0b9eafccd811e617939e029b757db66dadc8f93   IPs   35.183.81[.]182 66.154.127[.]38 66.154.127[.]39 8.218.44[.]75 97.107.96[.]14   CNC Requests   GET /linux GET /linux_sign GET /miner GET /miner_sigg GET /winminer GET /winminer_sign GET /windows_sign GET /windows Updated July 20, 2023, at 1:08 p.m. PT.   ... View more

    Discuss the new Network Investigate Graph and how it simplifies and enhances investigation. ... View more

By  Shashank Chandramohan, Senior Customer Success Engineer    In the past, application teams would be required to code from scratch, from building an application to releasing a new version, at best, every one or two years using standard shipping distribution methods. Today, application teams often use third-party open-source resource libraries and the cloud to get their products into the hands of users. These methods have sped up development to the point where application teams can release much faster, such as once a month or once a week.    Information security has had to adopt a new model to span the application lifecycle to keep up with the development speed, new technologies, and infrastructure changes.    At Palo Alto Networks, we use the Code & Build, Deploy, Run (CBDR) framework. With this approach, you have four phases to prevent misconfigurations that can lead to vulnerabilities.    The phases are   Code - Writing the code to create the resource. Build - Compiling the resource and its configuration. Deploy - Deploying the resource to where it is housed. Run - Running the resource and the live environment in which it is hosted.   This article focuses on the CBDR framework's final phase, the Run phase. If you want to start from the first phase, you can read about the Code & Build or Deploy lifecycle phases by clicking the blog links above.   Even though most successful exploits and breaches result from misconfigurations and vulnerabilities introduced in the Code & Build or Deploy phases, maintaining security is still crucial in the Run phase because vulnerabilities and exploits can be introduced in any phase of the application lifecycle. Run focuses on securing your workloads in the cloud with your security infrastructure, maintaining network security, and keeping an eye out for breaches, given that assets have already been deployed and are now externally facing. Figure 1 - use cases of Prisma Cloud during the Run Phase   In the Run Phase, you're preventing and detecting breaches trying to access your production assets, network workloads, identities, and data. Prisma Cloud can help your organization’s security professionals detect, analyze, and remediate the common issues that appear in live environments, which range from crypto-jacking, where someone uses your Cloud resources to do crypto mining, to ransomware.    The Run phase’s security should not depend on only daily and infrequent scans. Daily scans can miss costly breaches and malware that is gone by the time abnormal behavior is detected. In a modern production environment, ephemeral cloud resources might only exist for minutes or hours, so it's essential to have a solution that continuously monitors and looks for vulnerabilities and attacks while the resources are active.   Prisma Cloud secures your runtime environment using predictive and threat-based protections. It can run and deliver results in near real-time, 24/7/365, eliminating the missed spots from when your resources were checked only once or twice a day. Your security personnel can be notified and start working on threats within minutes, saving time and money at scale.   By continuously monitoring your runtime environments, Prisma Cloud goes beyond protecting you from known vulnerabilities and can detect the suspicious behavior of a zero-day vulnerability. Using our machine-learning models based on what is normal for your resources - if behavior deviates from the norm and is malicious, you will be alerted and able to act quickly.    Prisma Cloud uses Palo Alto Wildfire to detect previously unseen targeted malware and advanced persistent threats. And best of all, we bring the resources and research from our world-renowned Unit 42 Security Group to help protect your runtime environment.   Drilling Down Prisma Cloud can identify and remediate issues to secure your assets with the following capabilities:   Compliance and Governance Misconfiguration and Threat Detection  Vulnerability Management Runtime Security Web App and API Security  Integrated Access Management Security Data Security Network Security.      Compliance and Governance  Cloud compliance comprises the procedures that ensure that your cloud environment complies with your governance rule. When you build a compliant cloud environment, your environment conforms to one or more specific sets of security and privacy standards. Some common compliance frameworks include PCI DSS, GDPR, FedRAMP, and various versions of NIST. Prisma Cloud has you covered and comes with over 20 of the most commonly used compliance frameworks for use out-of-the-box , and you can tailor and create your own rules and policies for your organization’s specific needs, making it simple to set up and maintain compliance. You can also view, assess, report, monitor, and create reports that contain summary and detailed findings of security and compliance risks in your cloud environment on one or more cloud accounts and review your cloud infrastructure's health and compliance posture.    Figure 2- The Prisma Cloud Compliance Overview screen includes a line graph to the left showing the number of resources that exist, have failed, and passed on a monthly timeline. There is also a bar graph on the right that shows compliance coverage based on compliance frameworks. The Compliance Overview screen allows you to assess your compliance trends and coverage over time at a glance.   Web Application and API Security (WAAS) WAAS enhances the traditional Web Application Firewall (WAF) protection model by deploying closer to the application, efficiently scaling up or down, and allowing for inspection of "internal" traffic (east-to-west) from other microservices as well as inbound traffic (north-to-south). Prisma Cloud supports both inline and out-of-band WAAS , which you can use on your hosts and containers.  Inline WAAS offers more protection and features at the cost of using more resources in your cloud. Out-of-band WAAS allows you to run your production loads unchanged, with the WAAS monitoring done elsewhere in your network.    Prisma Cloud WAAS can block new zero-day attacks as soon as they are identified without waiting for modified applications.    Some Highlights of WAAS’s capabilities are: OWASP Top-10 Coverage - Protection against most critical security risks to web applications, including injection flaws, broken authentication, broken access control, security misconfigurations, etc. API Protection - WAAS can enforce API traffic security based on definitions or specs. Access Control - WAAS controls access to protected applications using Geo-based, IP-based, or HTTP Header-based user-defined restrictions. File Upload Control - WAAS secures application file uploads by enforcing file extension rules. Detection of Unprotected Web Applications - WAAS detects and flags unprotected web applications in the radar view. Penalty Box for Attackers - WAAS supports a 5 minutes ban of IPs triggering one of its protections to slow down vulnerability scanners and other attackers probing the application. Bot Protection - WAAS detects good-known bots and other bots, headless browsers, and automation frameworks. WAAS can also fend off cookie droppers and other primitive clients by mandating the use of cookies and Javascript for the client to reach the protected origin. DoS Protection - WAAS can enforce rate limitations on IPs to protect against high-rate and "low and slow" layer-7 DoS attacks.   Figure 3- Prisma Cloud’s WAAS Explorer dashboard in Prisma Cloud   There are four graphs:  Web protection coverage graph: how many critical  unprotected and vulnerable web apps you have with a line for high, medium, low & none.  Activity overview line graph: the number of policy changes, total traffic, access control, API, DoS, Custom, and WAF activities.  Line graph: the inspected traffic by WAAS, showing how many requests and bytes with the WAAS actions by effect.  Bar graph: total attacks per type and a summary of the WAAS configured policies & rules.   Runtime Security Runtime security is a vast set of features that protect containers and threat-based active protection for running containers, hosts and serverless functions. Threat-based protection includes capabilities like detecting when malware is added to a workload or when a workload connects to a botnet - all in real time. With Prisma Cloud, you can use both agent-based and agentless-based runtime defense and security separately or simultaneously. Agent-based can block threats in real-time, such as crypto mining and malicious code but is more resource intensive. With limited resources, agentless scanning can cover your entire cloud without deploying agents on every host. With both agent-based and agentless scanning, you can use Prisma Cloud to detect changes to the file system, network, and process activity, with each sensor having its own set of rules and alerting - keeping you protected no matter the number of resources you have available.     Data Security In the Run phase, data security is crucial for preventing leaks of personally identifiable information (PII) and sensitive data that may have been overlooked. With so many resources being run on your workloads, it is difficult to scan and ensure that none of them have potentially exposed data.    Prisma Cloud has 600 data profiles & patterns out of the box and is customizable for your organization’s use cases. For example, you can set various roles at your organization to only see the data masked . This provides your organization with the principle of least privilege, ensuring that only authorized users can access sensitive data.   Conclusion With faster development and release times come new technologies and challenges. Instead of relying on past methods that only scan and monitor once or twice daily, teams need real-time coverage of resources that can scale. Prisma Cloud can scale to meet these needs with automation and customizable tools that cover you from Compliance and Reporting to Runtime Security and WAAS.   About the Author     ... View more

    Join us to talk about the latest releases in Code Security, include our upcoming new module release, that expands supply chain security and simplifies finding and prioritizing issues. We’ll show a teaser for our upcoming CI/CD Security launch, enhanced Projects page, new integrations with JetBrains IDEs, Terraform Cloud and Enterprise, expanded SCA and Terraform support and more. ... View more

By Mark Davis, Customer Success Engineer   Introduction  A common customer question is how to view host vulnerabilities in the Asset Inventory for each Cloud Service Provider. In this article, we will focus on Azure, following up with articles for GCP and AWS.     Kubernetes is a popular container orchestration tool.  Most Cloud Service Providers have a managed offering.  Azure has AKS, Google offers GKE, AWS has EKS and Red Hat offers RedHat openshift.   The container workloads for all of these managed offerings run on host machines and those machines can contain vulnerabilities. The Prisma Cloud Command Center dashboard is the first high level dashboard that provides visibility into Vulnerabilities, and its purpose is to identify top issues by severity for hosts and images.  In order to filter based on a host name, severity or how many resources it will display, it is recommended to explore the asset inventory.   Figure 1 - Command Center Main Dashboard_palo-alto-networks     Figure 2 - Command Center Top Vulnerable Hosts Dashboard_palo-alto-networks    The updated Asset Inventory can now allow you to view host vulnerabilities that previously required you to view from the Compute module.  At a later point in the article, we will cover how to view vulnerabilities in your Azure kubernetes worker nodes directly from the Asset Inventory and Asset explorer page.   The host vulnerabilities in question will exist on the kubernetes service worker nodes.  To view the worker nodes with vulnerabilities, we need to first identify the names they are assigned in Azure.  The Azure kubernetes service creates a resource group during cluster creation that begins with “mc_” . Normally it will contain the syntax of the resource group used and the cluster name.  The worker nodes and all of the other resources required to run the cluster are placed in this mc_ resource group.     The below steps will show you how to locate the worker nodes names using the Azure GUI and CLI. Note : If you already have the worker node names you can skip to step 4. If you have access to the aks cluster and the .kube/config, the CLI is the fastest way to capture the worker node names. How to Find the Resource Names in Azure Kubernetes Nodes GUI method The detected vulnerabilities will not show up under the Azure Kubernetes service in the Prisma Cloud Asset Inventory dashboard, or after selecting the service to view multiple clusters.  The below screenshot shows the Azure kubernetes service in the Asset Inventory view. We notice how under the vulnerabilities column nothing is reported under vulnerabilities.  This is because the vulnerabilities will report under the actual worker nodes.   Figure 3_palo-alto-networks   We need to first locate the k8s node pool names that were assigned in Azure.   Step 1.  Log into the Azure portal - from the search bar at the top, type KUBERNETES SERVICES . Select the purple kubernetes services icon on the left:      Figure 4_palo-alto-networks   Step 2. Select the name of your k8s cluster from the list displayed, there may be several, so select the one of interest to you:     Figure 5_palo-alto-networks   Step 3. The next page displays the overview, resources, settings and monitoring parameters for the selected cluster.  Under settings, click Node Pools:     Figure 6: Settings > Node pools  _palo-alto-networks   Step 4. The next page will display the Node pool name as well as node count and state.  Click on the tab to the right of node pools named Nodes . This tab will list out the full name of the virtual machine scale set node name. We need to capture the node names like the example A listed below.   Example A - aks-nodepool1-31658136     Figure 7  - Nodes_palo-alto-networks   The first 3 names and numbers between the hyphens suffice to locate the resources in Prisma Cloud.  How to Find the Resource Names in Azure Kubernetes Nodes CLI method The below steps are how to locate the k8s node names from the Azure Cloud Shell or CLI.    Step 5. Log into the Azure Portal, to the right of the search bar click on the cloud shell icon.   Figure 8 - Azure Portal_palo-alto-networks   Step 6. Authenticate to your cluster and type kubectl get nodes     Figure 9: CLI_palo-alto-networks    Step 7. Collect the node name from the output.   Step 8. Now that you have the node names, we need to log into Prisma Cloud. Once you have logged in, please go to Inventory and select the Assets .     Figure 10: Inventory > Assets_palo-alto-networks    From the Assets inventory Page, continue to filter by Resource Type = Azure Virtual Machine     Figure 11 - Asset Inventory > Resource Type_palo-alto-networks    The filtered results will be displayed at the bottom of the page.  Click on the total number of assets listed for Azure Compute.     Figure 12: Service Name > Azure Compute > Total_palo-alto-networks     This will take you to the Asset Explorer page and the below filters will be applied.   Service Name = Azure Compute Cloud Type = Azure Date = Most Recent Resource Type = Azure Virtual Machine     Figure 13: Asset Explorer_palo-alto-networks     The applied filter will display the results of all of the virtual machines running in the Azure subscription or tenant.  This page also provides visibility into the alerts and vulnerabilities we are looking for on the AKS worker nodes.     Figure 14: Asset Explorer Details_palo-alto-networks     To locate the worker nodes we identified in the earlier steps from this list, we need to filter by the node names we collected from using the GUI or CLI method.   Type in the node name in the search bar to the far right   Figure 15: Search bar_palo-alto-networks     The Asset Explorer will now display the worker nodes in your AKS cluster as well as all of the alerts, severities and vulnerabilities.     Figure 16: Asset Explorer_palo-alto-networks     How is this information helpful?   The details in the Asset Explorer page expand on the visibility you get from Compute\Monitor\Vulnerability\Hosts by providing additional information about tags, related items and the worker nodes audit trail. What’s Next on the Asset Explorer page?   You can download this high level view by clicking the download link for a csv file to be shared and reviewed.   Figure 17: Download csv_palo-alto-networks       Figure 18: CSV file_palo-alto-networks     Clicking on any of the vulnerabilities found will display the Type, CVE name and Risk factor.     Figure 19 - Vulnerabilities_palo-alto-networks      Placing the cursor over the Risk factor will display the attack complexity, attack vector and severity details.     Figure 20 - Risk Factor_palo-alto-networks     Downloading this report will create an external findings csv file that contains all of the vulnerabilities for the selected host. This report can be given to a team to remediate from the Asset Explorer dashboard in Prisma Cloud.      Figure 21: CSV output_palo-alto-networks     Conclusion     In summary, this article guides you through the steps to  view host vulnerabilities in your Azure kubernetes worker nodes directly from the Asset Inventory and Asset explorer page. Also included the process to locate the node names for a given AKS cluster using the Azure Portal and the CLI.  Once we identified the names, we used filters in the Asset Inventory page to view vulnerability data that normally is displayed in Compute.  Using the Asset Explorer is another way to obtain visibility into your environment and review the audit trail.     References:  Prisma Cloud Admin  Prisma Cloud Dashboards -- Asset Inventory     About the Author: Mark Davis is a Customer Success Engineer on the Prisma Cloud team, specializing in solving enterprise customer questions by empowering the customers with knowledge and guidance in protecting cloud resources and workloads.  ... View more

  By RD Singh, Sr. Customer Success Engineer   Prisma Cloud Code Security helps to detect mis-configured IaC templates based on various standards and best practices. It also helps findings vulnerabilites in open source packages and their depedencies. Watch this demo with RD Singh, Sr. Customer Success Engineer, to learn how to connect your IDE with Prisma Cloud Code Security. To read the step-by-step instructions outlined in this video, visit our TechDoc:  https://docs.paloaltonetworks. com/prisma/prisma-cloud/ prisma-cloud-admin-code- security/get-started/connect- your-repositories/connect- vscode ... View more

    Join us to talk about the latest release in Data Security, learn more about Data Security Posture Management. We will discuss how to protect your data in your cloud infrastructure with Prisma Cloud Data Security for AWS and Azure. ... View more

By Ben Nicholson, Global Practice Lead - Prisma Cloud     Application modernization is driving organizations to the cloud. Rapid cloud adoption without both continuous visibility and proactive threat prevention throughout the development lifecycle leaves applications and organization security with significant risk t o address this gap.  Prisma Cloud provides code-to-cloud coverage to centralize your cloud security for lift-and-shift as well as cloud-native applications. We are launching a new guided focus to secure the code, infrastructure, workloads, data and applications across your multi-cloud and hybrid environments in a single platform. ... View more

By Taylor Smith, Senior Product Marketing Manager    You can now create custom secrets policies using regular expression patterns. Once custom policies are defined, Prisma Cloud will search for matches to your regular expressions across your repositories, including in integrations and Checkov. This way, you can easily find secrets that follow organization-specific patterns, which is especially useful if your organization follows internal naming conventions for secrets such as API tokens.   Secrets can be defined via the Code Editor in the platform.   About the Author       ... View more

  The latest CSPM capabilities we have released are Near Real Time Ingestion, IBM CSPM Support, and Accelerated Visibility into Azure Cloud Native Services. We welcome you to join us as we showcase and demo these new functionalities. ... View more

By Paul Burega, CSE Team Lead   The Prisma Cloud product from Palo Alto Networks has a number of threat landscape views along with preventative tools to help mitigate the risks of a vulnerability, including zero-day vulnerabilities.     We will examine how Prisma Cloud can notify you of a CVE, what API calls can be used to find the resources affected by a CVE, and how to create a custom CVE to support zero-day vulnerabilities. This article will demonstrate how you as a security professional can get a better understanding around the threat landscape of your environment.  For purposes of example, we will use Log4J as our zero-day threat in this article.   The best way to handle any new vulnerability is to be proactive instead of reactive. This could be through the use of a runbook, cloud resource hygiene through scope labeling to know which resources belong to which team, a subscription to a threat intelligence feed that is actively monitored, or anything else that your organization may implement to be proactive.  As long as there are threat actors to infiltrate computing systems, there will always be a need to defend against these threat actors. However, this also means that to efficiently defend these types of systems, there is a need to be proactive and, to some extent, innovative.    To start, you need to have knowledge as to what your current computing environment looks like and a way that any changes to that relative baseline can be communicated to you or your security team. In Prisma Cloud Workload Protection, there are several ways that these communication notifications can be set up to enable you to have thresholds of reporting from an incident response team to executive leadership. Within the context of Log4J, allow us to take a look at setting up a way to identify the scope of CVE detection through tagging and correlating that tag to a vulnerability rule that notifies an alert profile.   As in any problem solving use case, it is important to set the scope of work. In Prisma Cloud CWPP, there is a “Manage” menu, with a section dedicated to “Collections and Tags.” Once you have navigated to this view, click on the “Tags” tab on the top left, to be taken to the view that will help us in setting the scope of how to detect a package, the potential individual packages to detect encompassed by a CVE, the types of resources to detect the package(s) in, and the CVE correlated to the package(s).    In order to set this tag scope, the first step is to create a tag definition to be populated. Once you click the “Tag Definition” drop-down menu and select the “Add Tag” button, you can populate the tag name as has been done in this screenshot:   Figure 1: Create new tag_palo-alto-networks    Once this tag is defined, you can navigate to the tag assignment section and assign the scope of what the tag will define:    Figure 2: Create new assignment_palo-alto-networks   As you can see from these menus there is the capability to get granular in the package scope to the software packages corresponding to this CVE, in the threat intelligence stream, as well as the resource scope of where to check for the chosen package set. To have this be as comprehensive as possible you can select “All packages” and “All resources for the scope”.    Next let’s create the link between the scope of what to detect and the resource that we want to scan to detect the CVE through associating the tag with a vulnerability rule. To do this, navigate to the “Defend” menu of the CWPP console and click the “Vulnerabilities” section. Within this section there will be tabs that correspond to different types of cloud resources. We will create two rules in the “Images” resource type under the “CI” and “Deployed” tabs, which correlate to scanning continuous integration build pipelines and deployed image environments that have been onboarded into the console.   In the “Images” tab under the secondary “CI” tab, click on the “Add Rule” button.  This will bring up a dialog box where we can define the scope of the vulnerability rule through associated collections, as well as the configuration option we will need in the “Advanced Settings” section to create the link to the Log4J tag. It is important to note that this assumes that your collections are already where you need them to be in your environment for scoping cloud resources. It is also important to note that the “Alert Threshold” and “Block Threshold” toggles of the “Severity based actions” section should be set to off, as you can see below:   Figure 3: Scoping CI Vulnerability Rule_palo-alto-networks    To create the link to the Log4J tag within the “Advanced Settings” portion of the vulnerability rule, click on the “Advanced Settings” link to populate this within the dialog box and then click the “Add Exception” button. After selecting the “Tag” option instead of the “CVE” option, you can select the tag name of the Log4J tag from the menu. Even though you can set up this rule through the CVE, it is better to utilize the tag scoping functionality to be able to look at individual packages encompassed by a CVE, instead of every package due to the types of environments that you are scanning. Once the tag is added as an exception, you should be looking at something similar to this:   Figure 4: Correlating Tag to New CI Rule_palo-alto-networks   If you wanted to fail a CI build based on the detection of what is encompassed by the Log4J tag you could select the “Fail” effect, but for this article, we are going to keep the effect as being “Alert.” Based on the current capabilities of alert notification profiles, this rule will not be able to correspond to an alert but this configuration will show you how to potentially fail builds in a continuous integration pipeline based on detected CVEs or granularly tagged packages within a CVE.   To scan deployed images, we can configure a similar vulnerability rule within the “Deployed” tab of the images resource type. After navigating to this tab, within the same menu of the CWPP console, select the “Add Rule” button. In the same way that the CI rule was originally set up, the “Alert threshold” and “Block threshold” should be toggled off in order to ensure that the detection scope of the rule is only set to the correlated tag, as can be seen below. One thing to note here is that in your collections selection, you can specify the collections in your environment that have been set up to include resources that have images deployed with potential software configurations that would include Log4J.    Figure 5: Creating New Deployed Images Vulnerability Rule_palo-alto-networks    Also in the same way that the tag was added as an exception in the previous rule, the same configuration needs to be made in this rule to set the proper scope. Figure 6: Correlating Tag to Deployed Images Vulnerability Rule_palo-alto-networks Next, let’s set up the alert notification profile. To make this relatively easy, we are going to send this alert to an email address from the Prisma Cloud console, but depending on if you have prior alert profiles set up, you can integrate at least a portion of this process to notify the existing alert profiles.    Within the Prisma Cloud CWPP console, you can navigate to the “Manage” section and select the “Alerts” link. In the “Manage” tab of this view, you can create a new alert profile by clicking on the “Add Profile” button on the right. To configure the initial screen options, you can name the profile and then select the provider as “Prisma Cloud” and the integration as “Email” as can be seen below:   Figure 7: Alert Notification Profile Provider Configuration_palo-alto-networks   After you have configured, you can then correlate the vulnerability rule that was created in the previous step to this alert profile through paralleling the setup of the next view in the dialog:   Figure 8: Alert Notification Profile Scoping_palo-alto-networks   Since the email notification is configured to be sent with Prisma Cloud as the “Provider” via an email integration, the only portion of the settings within this alert profile that we will need to set up is a static list of email addresses. This can also just be one email address to be able to test the alert. There are many options to potentially configure within an alert profile depending on your needs and where the information from the console can be consumed internally.   Figure 9: Setting Email(s) To Notify_palo-alto-networks    Finally, in the summary of the profile, there is an option to send a test email to make sure the specifications will work as intended. Once selecting this option, a green confirmation message will appear.   Figure 10: Sending Test Email_palo-alto-networks   You can then check the email address, or list of addresses, for an email that will look like the one below.   Figure 10: Sending Test Email_palo-alto-networks   After you have confirmation that this test email is received, you can save the alert profile.    Conclusion   You can now set up and create an email integration that is scoped to the tag associated with a vulnerability, such as Log4J, to be able to send alerts when that CVE is detected within the specified collections of the deployed images vulnerability rule .    Additionally, you can create a rule that will fail builds in your continuous integration environments based on the same detection scope.  By  setting this up with a tag, you can also test different packages encompassed by the CVE within the types of environments that you have scoped to the rule.    You now have a template to set this procedure for any CVE in the Prisma Cloud intelligence stream to have a granular look at the different packages impacted, along with a streamlined approach to getting notifications of detections of a CVE in your cloud environment.    You are now on your way to be better protected.   About the Author: Paul Burega is a  CSE Team Lead . Paul utilizes collaborative approach to break down complex problems into solutions for global enterprise customers and leverage his multi-industry knowledge to inspire success. ... View more

By Jonathan King, Customer Success Engineer   Introduction    Prisma Cloud allows you to create policies to ensure that your Cloud Security Posture Management is in compliance with best practices and the needs of your organization.  These policies create alerts which need to be evaluated and also indicate which cloud objects need to be updated to be in compliance.    Managing these alerts is a task that many organizations find difficult as the number of alerts increases. Prisma Cloud allows you to define an auto-remediation to correct certain alerts.  However, oftentimes an organization requires much more customization and integration with other tools that they are using.    This article describes how to increase your alert automation and integrate with other tools by using a security orchestration, automation, and response (SOAR) platform from Palo Alto Networks.   What is Cortex™ XSOAR?   Cortex™ XSOAR is a comprehensive security orchestration, automation and response platform that unifies case management, automation, real-time collaboration and threat intel management to serve security teams across the incident lifecycle. The Cortex XSOAR platform includes more than 270 out-of-the-box playbooks to automate and orchestrate any security use case.   Prisma™ Cloud Alert Handling   Prisma™ Cloud allow you multiple options to deal with alerts.: You can configure your alert handling to automatically remediate cloud security policy violations using a set of CLI commands.  You can configure your alert to be sent to external systems such as Email Jira ServiceNow   Which allows you to prioritize and categorize alerts with different teams in your organization.:  You can configure your alert to be sent to Cortex™ XSOAR and have the alert resolved using a playbook. These playbooks allow a different approach to handling alerts by providing your organization with a remediation that is custom tailored to your environment and tools.    Alert Remediation   We are going to give examples of alert remediation in Prisma™ Cloud  and Cortex™ XSOAR.    1.  Prisma™ Cloud   Allows creating an auto remediation using a set of CLI commands for the respected Cloud Service Provider (CSP), such as AWS, Azure, GCP, OCI… for the alert in question.  Figure 1: Prisma Cloud Policy Auto-Remediation Configuration_palo-alto-networks   This may work perfectly fine for what you are looking to do.  But what if you need more options and flexibility?    2.  Cortex™ XSOAR   Additional options and flexibility are available when using Cortex™ XSOAR to remediate an alert.  Not only can you resolve the alert, but you can also take any additional actions needed in your specific environment.  Fig 2. Cortex XSOAR Playbook Example_palo-alto-networks   These playbooks will be beneficial for not only remediating common issues (such as those in Prisma Cloud using Auto-Remediation) but also for sending out custom actions to address other teams, remediating complex resources.   Alerts vs Incidents   With the Prisma™ Cloud and Cortex™ XSOAR outbound or push-based integration, you can send a Prisma™ Cloud alert generated by a policy violation to Cortex™ XSOAR to process as an incident. Connecting these two products enables your Security operations team to define custom playbooks or use the out-of-box playbooks on Cortex™ XSOAR to create multi-step workflows for incident management of your cloud resources. This is an alternative to the pull-based integration that you can configure from Cortex™ XSOAR.   Push-based integration sends alerts as they happen from Prisma™ Cloud to Cortex™ XSOAR. Pull-based integration has Cortex™ XSOAR logging into Prisma™ Cloud and checking for alerts, every n minutes, where n is a configuration option.    Using the policy ID in the alert, Cortex™ XSOAR categorizes the alert as a specific incident type. For an incident type, the Prisma™ Cloud alert payload is mapped to a Cortex™ XSOAR layout that specifies the incident fields for data classification and mapping on Cortex™ XSOAR.    The current list of Cortex™ XSOAR incident types are:  AWS CloudTrail Misconfiguration AWS EC2 Instance Misconfiguration  AWS IAM Policy Misconfiguration Azure AKS Misconfiguration Azure Network Misconfiguration Azure SQL Misconfiguration Azure Storage Misconfiguration GCP Compute Engine Misconfiguration GCP Kubernetes Engine Misconfiguration  Prisma Cloud   If a custom policy is being used in Prisma Cloud which you would like to use as an incident, our best practices would be to create a custom incident in XSOAR to complement and focus on the custom Prisma Cloud policy you have created. This way not only the details of the incident are shown but also a tailored strategy that is specific to your policy needs to help resolve the issue effectively.   If the Prisma™ Cloud policy ID is not categorized to a specific incident type, it is automatically mapped to the generic Prisma Cloud incident type. Every incident type is mapped to a Cortex™ XSOAR layout and associated with a playbook to enable auto-remediation of the violating resource, except for the generic Prisma Cloud incident type. Ref: Integrate Prisma Cloud with Cortex XSOAR   Integrating Cortex™ XSOAR into Prisma™ Cloud   To setup a Cortex™ XSOAR integration in Prisma™ Cloud select  Settings > Integrations > Add Integration > Select Cortex XSOAR   Fig 3: Adding Integration for Cortex™ XSOAR_palo-alto-networks   Once you have added in the Name, Description, XSOAR FQDN/IP Address*, and API Key, then you can run a test to verify the integration is successful (and save.) For more information please refer to the link at the bottom of this page [1]. NOTE: Make sure that if you are using a multi-tenant deployment to enter the tenant URL without HTTP or HTTPS.   Create Prisma™ Cloud Alert Rule   Next, you add this Cortex™ XSOAR integration into an alert rule[2].  Best practice is to focus on policies that your organization require to have complex resolution.  You don’t need to send all alerts to Cortex™ XSOAR.    Go to Alert Rules > Edit or Add a New Alert rule > Verify that Alert Notifications is Checked >  Add your Targets and Policies you want Alerted to XSOAR >  Under “Configure Notifications” go under Cortex XSOAR and enable with the integration you want selected in the drop-down > Click Finish This completes setting up Prisma™ Cloud to send alerts to Cortex™ XSOAR for incident processing.     Now we need to set up the Cortex™ XSOAR to receive the alerts.    Setting up the integration in Cortex™ XSOAR   Many of the Prisma™ Cloud alerts are already categorized already out-of-the-box (see Alerts vs Incidents above). If the Prisma™ Cloud policy ID is not categorized to a specific Cortex™ XSOAR incident type, it is automatically mapped to the generic Prisma Cloud incident type by default.   XSOAR Marketplace Prisma Cloud installation   Before you can see Prisma incidents in XSOAR, you need to install the Prisma Cloud by Palo Alto Networks content pack from the Cortex XSOAR Marketplace .   To set this up in Cortex XSOAR: Marketplace > Browse > Select Prisma Cloud by Palo Alto Networks content pack and Install >  Enable the connection by Settings > Objects Setup > Classification & Mapping > Click the Triple Dot and select API endpoint Mapping > For the Prisma Cloud Row, select Prisma Cloud App - Classifier and Prisma Cloud App - Incoming Mapper > And Save   Fig 4: Mapping Prisma to XSOAR_palo-alto-networks   Once this has been successfully mapped, you can view incident types by the Prisma Cloud App - Classifier under    Settings > Objects Setup > Incidents > Classification & Mapping.   You can click on Prisma incidents and view their playbooks by going to the War Room Tab and selecting their playbook that is associated. From here, you can also manage how this playbook functions and how it will integrate into your environment.   The Playbooks range from simple to  very complex depending on the outcome that is desired. Start with the out-of-the-box solutions to see how they perform in your environment. Once you have them working, feel free to add additional functionality to customize the solution to fit your needs.   Security Group Misconfiguration Example   Take the Prisma Cloud policy: "AWS Security Groups Allows Internet Traffic To TCP Port"   We want to make sure that a Security Group misconfiguration is being tracked within Cortex XSOAR, when it is alerted as a policy within Prisma Cloud. We see from the following Playbook that as long as the resource is still available then auto-remediation will take place to solve this issue. Alternatively, the solution is to notify the customer of this incident and perform manual steps to remediate. Fig 5: Playbook Example of a Misconfigured AWS Security Group_palo-alto-networks   Conclusion   We have talked about how Prisma Cloud can remediate alerts using the CSP CLI.  By adding a Cortex XSOAR integration, Prisma Cloud can push alerts as they occur to Cortex XSOAR, and the incidents will be processed by runbooks. These Cortex XSOAR runbooks allow greater functionality in being able to remediate an alert automatically, as well as provide the ability to route the alert information to other active applications or systems within your organization.    Cortex XSOAR provides a mechanism for you and your team to customize the handling of alerts from Prisma Cloud and automate the response to more alerts leaving fewer alerts to be processed by your security team.    Reference:  [1] Integrate Prisma Cloud with Cortex XSOAR [2] Prisma Cloud Alert Rule   About the Author:   Jonathan King is a Cloud Security Engineer on the Prisma Cloud CSPM team, specializing in supporting all non-compute solutions for Prisma Cloud  AWS, Azure, GCP, OCI, and Alibaba. ... View more