From c74cdab04d701071e8da0b60b386923f541c8c61 Mon Sep 17 00:00:00 2001
From: Leonardo Grasso <me@leonardograsso.com>
Date: Fri, 1 Sep 2023 11:58:47 +0200
Subject: [PATCH] wip: testing with CI

Signed-off-by: Leonardo Grasso <me@leonardograsso.com>
---
 rules/falco_rules.yaml | 998 -----------------------------------------
 1 file changed, 998 deletions(-)

diff --git a/rules/falco_rules.yaml b/rules/falco_rules.yaml
index a675f5f63..f1a37137c 100644
--- a/rules/falco_rules.yaml
+++ b/rules/falco_rules.yaml
@@ -397,21 +397,6 @@
 - macro: allowed_ssh_hosts
   condition: (never_true)
 
-- rule: Disallowed SSH Connection
-  desc: > 
-    Detect any new SSH connection on port 22 to a host other than those in an allowed list of hosts. 
-    This rule absolutely requires profiling your environment beforehand. Network-based rules are extremely 
-    crucial in any security program, as they can often provide the only definitive evidence. However, 
-    effectively operationalizing them can be challenging due to the potential for noise.
-  condition: > 
-    inbound_outbound 
-    and ssh_port 
-    and not allowed_ssh_hosts
-  enabled: false
-  output: Disallowed SSH Connection (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_deprecated, host, container, network, mitre_lateral_movement, T1021.004]
-
 # These rules and supporting macros are more of an example for how to
 # use the fd.*ip and fd.*ip.name fields to match connection
 # information against ips, netmasks, and complete domain names.
@@ -430,22 +415,6 @@
 - list: allowed_outbound_destination_domains
   items: [google.com, www.yahoo.com]
 
-- rule: Unexpected outbound connection destination
-  desc: > 
-    Detect any outbound connection to a destination outside of an allowed set of ips, networks, or domain names. 
-    This rule absolutely requires profiling your environment beforehand. Network-based rules are extremely crucial 
-    in any security program, as they can often provide the only definitive evidence. However, effectively operationalizing 
-    them can be challenging due to the potential for noise.
-  condition: >
-    outbound 
-    and not ((fd.sip in (allowed_outbound_destination_ipaddrs)) or
-             (fd.snet in (allowed_outbound_destination_networks)) or
-             (fd.sip.name in (allowed_outbound_destination_domains)))
-  enabled: false
-  output: Disallowed outbound connection destination (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_deprecated, host, container, network, mitre_command_and_control, TA0011]
-
 - list: allowed_inbound_source_ipaddrs
   items: ['"127.0.0.1"']
 
@@ -455,22 +424,6 @@
 - list: allowed_inbound_source_domains
   items: [google.com]
 
-- rule: Unexpected inbound connection source
-  desc: > 
-    Detect any inbound connection from a source outside of an allowed set of ips, networks, or domain names. 
-    This rule absolutely requires profiling your environment beforehand. Network-based rules are extremely crucial 
-    in any security program, as they can often provide the only definitive evidence. However, effectively operationalizing 
-    them can be challenging due to the potential for noise.
-  condition: >
-    inbound 
-    and not ((fd.cip in (allowed_inbound_source_ipaddrs)) or
-             (fd.cnet in (allowed_inbound_source_networks)) or
-             (fd.cip.name in (allowed_inbound_source_domains)))
-  enabled: false
-  output: Disallowed inbound connection source (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_sandbox, host, container, network, mitre_command_and_control, TA0011]
-
 - list: bash_config_filenames
   items: [.bashrc, .bash_profile, .bash_history, .bash_login, .bash_logout, .inputrc, .profile]
 
@@ -499,61 +452,9 @@
 - macro: user_known_shell_config_modifiers
   condition: (never_true)
 
-- rule: Modify Shell Configuration File
-  desc: > 
-    Detect attempts to modify shell configuration files, primarily aimed at establishing persistence by automatically inserting 
-    commands into scripts executed by shells. The upstream rule excludes shell processes because they often create unnecessary noise.
-    However, this might lead to missed detections. To customize the rule for your situation, you can fine-tune it using enhanced profiling. 
-    For example, you might want to only consider interactive shell processes (where proc.tty != 0).
-  condition: >
-    open_write 
-    and (fd.filename in (shell_config_filenames) or
-         fd.name in (shell_config_files) or
-         fd.directory in (shell_config_directories))
-    and not proc.name in (shell_binaries)
-    and not exe_running_docker_save
-    and not user_known_shell_config_modifiers
-  output: A shell configuration file has been modified (file=%fd.name pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority:
-    WARNING
-  tags: [maturity_incubating, host, container, filesystem, mitre_persistence, T1546.004]
-
-# This rule is not enabled by default, as there are many legitimate
-# readers of shell config files.
-- rule: Read Shell Configuration File
-  desc: > 
-    This rule detects attempts made by non-shell programs to read shell configuration files. It offers additional generic auditing. 
-    It serves as a baseline detection alert for unusual shell configuration file accesses. The rule "Modify Shell Configuration File" 
-    might be more relevant and adequate for your specific cases.
-  condition: >
-    open_read
-    and (fd.filename in (shell_config_filenames) or
-         fd.name in (shell_config_files) or
-         fd.directory in (shell_config_directories)) 
-    and not proc.name in (shell_binaries)
-  enabled: false
-  output: A shell configuration file was read by a non-shell program (file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority:
-    WARNING
-  tags: [maturity_sandbox, host, container, filesystem, mitre_discovery, T1546.004]
-
 - macro: user_known_cron_jobs
   condition: (never_true)
 
-- rule: Schedule Cron Jobs
-  desc: >
-    Detect scheduled cron jobs; this is a highly generic detection and certainly needs adjustments and profiling in your environment before 
-    operationalization. Simultaneously, exploiting the functionality of cron jobs is among one of the oldest TTPs used by adversaries.
-  condition: >
-    ((open_write and fd.name startswith /etc/cron) or
-     (spawned_process and proc.name = "crontab")) 
-    and not user_known_cron_jobs
-  enabled: false
-  output: Cron jobs were scheduled to run (file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority:
-    NOTICE
-  tags: [maturity_incubating, host, container, filesystem, mitre_execution, T1053.003]
-
 # Use this to test whether the event occurred within a container.
 
 # When displaying container information in the output field, use
@@ -918,45 +819,12 @@
 - macro: user_known_update_package_registry
   condition: (never_true)
 
-- rule: Update Package Repository
-  desc: > 
-    This rule generically detects updates to package repositories and can be seen as an auditing measure. 
-    Recommend evaluating its relevance for your specific environment.
-  condition: >
-    ((open_write and access_repositories) or (modify and modify_repositories))
-    and not package_mgmt_procs
-    and not package_mgmt_ancestor_procs
-    and not exe_running_docker_save
-    and not user_known_update_package_registry
-  output: Repository files get updated (newpath=%evt.arg.newpath file=%fd.name pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority:
-    NOTICE
-  tags: [maturity_sandbox, host, container, filesystem, mitre_execution, T1072]
-
 # Users should overwrite this macro to specify conditions under which a
 # write under the binary dir is ignored. For example, it may be okay to
 # install a binary in the context of a ci/cd build.
 - macro: user_known_write_below_binary_dir_activities
   condition: (never_true)
 
-- rule: Write below binary dir
-  desc: > 
-    Trying to write to any file below specific binary directories can serve as an auditing rule to track general system changes. 
-    Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful 
-    profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system 
-    changes, including compliance-related cases.
-  condition: >
-    open_write and evt.dir=< 
-    and bin_dir
-    and not package_mgmt_procs
-    and not exe_running_docker_save
-    and not python_running_get_pip
-    and not python_running_ms_oms
-    and not user_known_write_below_binary_dir_activities
-  output: File below a known binary directory opened for writing (file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: ERROR
-  tags: [maturity_sandbox, host, container, filesystem, mitre_persistence, T1543]
-
 # If you'd like to generally monitor a wider set of directories on top
 # of the ones covered by the rule Write below binary dir, you can use
 # the following rule and lists.
@@ -994,27 +862,6 @@
 - macro: user_known_write_monitored_dir_conditions
   condition: (never_true)
 
-- rule: Write below monitored dir
-  desc: > 
-    Trying to write to any file below a set of monitored directories can serve as an auditing rule to track general system changes. 
-    Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful 
-    profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system 
-    changes, including compliance-related cases.
-  condition: >
-    open_write and evt.dir=<
-    and monitored_dir
-    and not package_mgmt_procs
-    and not coreos_write_ssh_dir
-    and not exe_running_docker_save
-    and not python_running_get_pip
-    and not python_running_ms_oms
-    and not google_accounts_daemon_writing_ssh
-    and not cloud_init_writing_ssh
-    and not user_known_write_monitored_dir_conditions
-  output: File below a monitored directory opened for writing (file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: ERROR
-  tags: [maturity_sandbox, host, container, filesystem, mitre_persistence, T1543]
-
 # ******************************************************************************
 # * "Directory traversal monitored file read" requires FALCO_ENGINE_VERSION 13 *
 # ******************************************************************************
@@ -1041,24 +888,6 @@
 - macro: user_known_read_ssh_information_activities
   condition: (never_true)
 
-- rule: Read ssh information
-  desc: > 
-    This rule identifies attempts to read files within ssh directories using programs that are not related to ssh. It's a simple and 
-    versatile detection method that works well alongside more specific rules focused on sensitive file access. You have a couple of 
-    options for using this rule effectively: you can adjust the specialized rules to cover all the important scenarios and ensure 
-    precedence in rule smatching for those, or you can analyze the combined view of ssh-related file access across various rules on 
-    your downstream computing platform. Just like with other rules, you can narrow down monitoring to specific processes, or you can 
-    limit it to interactive access only.
-  condition: >
-    (open_read or open_directory) 
-     and (user_ssh_directory or fd.name startswith /root/.ssh)
-     and not user_known_read_ssh_information_activities 
-     and not proc.name in (ssh_binaries)
-  enabled: false
-  output: ssh-related file/directory read by non-ssh program (file=%fd.name pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: ERROR
-  tags: [maturity_incubating, host, container, filesystem, mitre_collection, T1005]
-
 - list: safe_etc_dirs
   items: [/etc/cassandra, /etc/ssl/certs/java, /etc/logstash, /etc/nginx/conf.d, /etc/container_environment, /etc/hrmconfig, /etc/fluent/configs.d. /etc/alertmanager]
 
@@ -1339,17 +1168,6 @@
     and not multipath_writing_conf
     and not calico_node)
 
-- rule: Write below etc
-  desc: > 
-    Trying to write to any file below /etc can serve as an auditing rule to track general system changes. 
-    Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful 
-    profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system 
-    changes, including compliance-related cases.
-  condition: write_etc_common
-  output: File below /etc opened for writing (file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: ERROR
-  tags: [maturity_sandbox, host, container, filesystem, mitre_persistence, T1098]
-
 - list: known_root_files
   items: [/root/.monit.state, /root/.auth_tokens, /root/.bash_history, /root/.ash_history, /root/.aws/credentials,
           /root/.viminfo.tmp, /root/.lesshst, /root/.bzr.log, /root/.gitconfig.lock, /root/.babel.json, /root/.localstack,
@@ -1418,41 +1236,6 @@
 - macro: mysqlsh_writing_state
   condition: (proc.name=mysqlsh and fd.directory=/root/.mysqlsh)
 
-- rule: Write below root
-  desc: > 
-    Trying to write to any file directly below / or /root can serve as an auditing rule to track general system changes. 
-    Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful 
-    profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system 
-    changes, including compliance-related cases. Lastly, this rule stands out as potentially the noisiest one among rules related 
-    to "write below.
-  condition: >
-    open_write and evt.dir=<
-    and root_dir
-    and proc_name_exists
-    and not fd.name in (known_root_files)
-    and not fd.directory pmatch (known_root_directories)
-    and not exe_running_docker_save
-    and not gugent_writing_guestagent_log
-    and not dse_writing_tmp
-    and not zap_writing_state
-    and not airflow_writing_state
-    and not rpm_writing_root_rpmdb
-    and not maven_writing_groovy
-    and not chef_writing_conf
-    and not kubectl_writing_state
-    and not cassandra_writing_state
-    and not galley_writing_state
-    and not calico_writing_state
-    and not rancher_writing_root
-    and not runc_writing_exec_fifo
-    and not mysqlsh_writing_state
-    and not known_root_conditions
-    and not user_known_write_root_conditions
-    and not user_known_write_below_root_activities
-  output: File below / or /root opened for writing (file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: ERROR
-  tags: [maturity_sandbox, host, container, filesystem, mitre_persistence, TA0003]
-
 - macro: cmp_cp_by_passwd
   condition: (proc.name in (cmp, cp) and proc.pname in (passwd, run-parts))
 
@@ -1560,26 +1343,6 @@
 - macro: user_known_write_rpm_database_activities
   condition: (never_true)
 
-# Only let rpm-related programs write to the rpm database
-- rule: Write below rpm database
-  desc: > 
-    Trying to write to the rpm database by any non-rpm related program can serve as an auditing rule to track general system changes. 
-    Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful 
-    profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system 
-    changes, including compliance-related cases.
-  condition: >
-    open_write
-    and fd.name startswith /var/lib/rpm
-    and not rpm_procs
-    and not ansible_running_python
-    and not python_running_chef
-    and not exe_running_docker_save
-    and not amazon_linux_running_python_yum
-    and not user_known_write_rpm_database_activities
-  output: rpm database opened for writing by a non-rpm program (file=%fd.name pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: ERROR
-  tags: [maturity_sandbox, host, container, filesystem, software_mgmt, mitre_persistence, T1072]
-
 - macro: postgres_running_wal_e
   condition: (proc.pname=postgres and (proc.cmdline startswith "sh -c envdir /etc/wal-e.d/env /usr/local/bin/wal-e" or proc.cmdline startswith "sh -c envdir \"/run/etc/wal-e.d/env\" wal-g wal-push"))
 
@@ -1603,59 +1366,12 @@
 - macro: user_known_db_spawned_processes
   condition: (never_true)
 
-- rule: DB program spawned process
-  desc: >
-    A program related to the database server creates an unexpected child process (other than itself). 
-    This is not supposed to happen and often follows SQL injection attacks. This behavioral detection could 
-    indicate potential unauthorized data extraction or tampering with the database.
-  condition: >
-    spawned_process
-    and proc.pname in (db_server_binaries)
-    and not proc.name in (db_server_binaries)
-    and not postgres_running_wal_e
-    and not user_known_db_spawned_processes
-  output: Database-related program spawned process other than itself (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_incubating, host, container, process, database, mitre_execution, T1190]
-
 - macro: user_known_modify_bin_dir_activities
   condition: (never_true)
 
-- rule: Modify binary dirs
-  desc: > 
-    Trying to modify any file below a set of binary directories can serve as an auditing rule to track general system changes. 
-    Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful 
-    profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system 
-    changes, including compliance-related cases.
-  condition: > 
-    modify 
-    and bin_dir_rename
-    and not package_mgmt_procs 
-    and not exe_running_docker_save 
-    and not user_known_modify_bin_dir_activities
-  output: File below known binary directory renamed/removed (file=%fd.name pcmdline=%proc.pcmdline evt_args=%evt.args evt_type=%evt.type evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: ERROR
-  tags: [maturity_sandbox, host, container, filesystem, mitre_defense_evasion, T1222.002]
-
 - macro: user_known_mkdir_bin_dir_activities
   condition: (never_true)
 
-- rule: Mkdir binary dirs
-  desc: >
-    Trying to create a directory below a set of binary directories can serve as an auditing rule to track general system changes. 
-    Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful 
-    profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system 
-    changes, including compliance-related cases.
-  condition: >
-    mkdir
-    and bin_dir_mkdir
-    and not package_mgmt_procs
-    and not user_known_mkdir_bin_dir_activities
-    and not exe_running_docker_save
-  output: Directory below known binary directory created (directory=%evt.arg.path evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: ERROR
-  tags: [maturity_sandbox, host, container, filesystem, mitre_persistence, T1222.002]
-
 # This list allows for easy additions to the set of commands allowed
 # to change thread namespace without having to copy and override the
 # entire change thread namespace rule.
@@ -1671,33 +1387,6 @@
 - macro: weaveworks_scope
   condition: (container.image.repository endswith weaveworks/scope and proc.name=scope)
 
-- rule: Change thread namespace
-  desc: >
-    An attempt to alter the namespace of a process (often performed while creating a container) through the setns syscall. 
-    Conversely, the same syscall setns is triggered when an unauthorized attempt is made to break out from the container 
-    to the host, for example, when using commands like `nsenter --target 1` and similar ones. Recommending to profile your 
-    environment and refine this rule for effective operationalization.
-  condition: >
-    evt.type=setns and evt.dir=<
-    and proc_name_exists
-    and not (container.id=host and proc.name in (docker_binaries, k8s_binaries, lxd_binaries, nsenter))
-    and not proc.name in (sysdigcloud_binaries, sysdig, calico, oci-umount, cilium-cni, network_plugin_binaries)
-    and not proc.name in (user_known_change_thread_namespace_binaries)
-    and not proc.name startswith "runc"
-    and not proc.cmdline startswith "containerd"
-    and not proc.pname in (sysdigcloud_binaries, hyperkube, kubelet, protokube, dockerd, tini, aws)
-    and not java_running_sdjagent
-    and not kubelet_running_loopback
-    and not rancher_agent
-    and not rancher_network_manager
-    and not calico_node
-    and not weaveworks_scope
-    and not user_known_change_thread_namespace_activities
-  enabled: false
-  output: Namespace change (setns) by unexpected program (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_incubating, host, container, process, mitre_privilege_escalation, T1611]
-
 # The binaries in this list and their descendents are *not* allowed
 # spawn shells. This includes the binaries spawning shells directly as
 # well as indirectly. For example, apache -> php/perl for
@@ -2040,23 +1729,6 @@
 - macro: user_sensitive_mount_containers
   condition: (never_true)
 
-- rule: Launch Privileged Container
-  desc: > 
-    Detect the initial process initiation within a privileged container, with exemptions for known and trusted images. 
-    This rule primarily serves as an excellent auditing mechanism since highly privileged containers, when compromised, 
-    can result in significant harm. For instance, if another rule triggers within such a privileged container, it could be 
-    seen as more suspicious, prompting a closer inspection.
-  condition: >
-    container_started 
-    and container
-    and container.privileged=true
-    and not falco_privileged_containers
-    and not user_privileged_containers
-    and not redhat_image
-  output: Privileged container started (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: INFO
-  tags: [maturity_incubating, container, cis, mitre_execution, T1610, PCI_DSS_10.2.5]
-
 # These capabilities were used in the past to escape from containers
 - macro: excessively_capable_container
   condition: >
@@ -2070,23 +1742,6 @@
     or thread.cap_permitted contains CAP_NET_ADMIN
     or thread.cap_permitted contains CAP_BPF)
 
-- rule: Launch Excessively Capable Container
-  desc: > 
-    Identify containers that start with a powerful set of capabilities, with exceptions for recognized trusted images. 
-    Similar to the "Launch Privileged Container" rule, this functions as a robust auditing rule. Compromised highly privileged 
-    containers can lead to substantial harm. For instance, if another rule is triggered within such a container, it might 
-    raise suspicion, prompting closer scrutiny.
-  condition: >
-    container_started 
-    and container
-    and excessively_capable_container
-    and not falco_privileged_containers
-    and not user_privileged_containers
-  output: Excessively capable container started (cap_permitted=%thread.cap_permitted evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: INFO
-  tags: [maturity_incubating, container, cis, mitre_execution, T1610]
-
-
 # For now, only considering a full mount of /etc as
 # sensitive. Ideally, this would also consider all subdirectories
 # below /etc as well, but the globbing mechanism
@@ -2119,21 +1774,6 @@
 - macro: container_entrypoint
   condition: (not proc.pname exists or proc.pname in (runc:[0:PARENT], runc:[1:CHILD], runc, docker-runc, exe, docker-runc-cur, containerd-shim, systemd, crio))
 
-- rule: Launch Sensitive Mount Container
-  desc: >
-    Detect the initial process launched within a container that has a mount from a sensitive host directory (e.g. /proc). 
-    Exceptions are made for known trusted images. This rule holds value for generic auditing; however, its noisiness 
-    varies based on your environment.
-  condition: >
-    container_started 
-    and container
-    and sensitive_mount
-    and not falco_sensitive_mount_containers
-    and not user_sensitive_mount_containers
-  output: Container with sensitive mount started (mounts=%container.mounts evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: INFO
-  tags: [maturity_sandbox, container, cis, mitre_execution, T1610]
-
 # In a local/user rules file, you could override this macro to
 # explicitly enumerate the container images that you want to run in
 # your environment. In this main falco rules file, there isn't any way
@@ -2145,20 +1785,6 @@
 - macro: allowed_containers
   condition: (container.id exists)
 
-- rule: Launch Disallowed Container
-  desc: >
-    Detect the initial process launched within a container that is not in a list of allowed containers. 
-    This rule holds value for generic auditing; however, this rule requires a good understanding of your 
-    setup and consistent effort to keep the list of allowed containers current. In some situations, 
-    this can be challenging to manage.
-  condition: > 
-    container_started 
-    and container 
-    and not allowed_containers
-  output: Container started and not in allowed list (evt_type=%evt.type user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: WARNING
-  tags: [maturity_sandbox, container, mitre_lateral_movement, T1610]
-
 - macro: user_known_system_user_login
   condition: (never_true)
 
@@ -2269,24 +1895,6 @@
 - macro: login_doing_dns_lookup
   condition: (proc.name=login and fd.l4proto=udp and fd.sport=53)
 
-# sockfamily ip is to exclude certain processes (like 'groups') that communicate on unix-domain sockets
-# systemd can listen on ports to launch things like sshd on demand
-- rule: System procs network activity
-  desc: >
-    Detect any unexpected network activity performed by system binaries that typically shouldn't perform network activity, including 
-    coreutils binaries (like sleep, mkdir, who, date, and others) or user management binaries (such as login, systemd, usermod, deluser, 
-    adduser, chpasswd, and others). This serves as a valuable baseline detection for network-related activities.
-  condition: >
-    inbound_outbound
-    and fd.sockfamily = ip 
-    and (system_procs or proc.name in (shell_binaries))
-    and not proc.name in (known_system_procs_network_activity_binaries)
-    and not login_doing_dns_lookup
-    and not user_expected_system_procs_network_activity_conditions
-  output: Known system binary sent/received network traffic (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_incubating, host, network, process, mitre_execution, T1059]
-
 # This list allows easily whitelisting system proc names that are
 # expected to communicate on the network.
 - list: known_system_procs_network_activity_binaries
@@ -2312,52 +1920,6 @@
 - macro: http_proxy_procs
   condition: (proc.name in (http_proxy_binaries))
 
-- rule: Program run with disallowed http proxy env
-  desc: >
-    Detect curl or wget usage with HTTP_PROXY environment variable. Attackers can manipulate the HTTP_PROXY variable's 
-    value to redirect application's internal HTTP requests. This could expose sensitive information like authentication 
-    keys and private data.
-  condition: >
-    spawned_process 
-    and http_proxy_procs 
-    and proc.env icontains HTTP_PROXY
-    and not allowed_ssh_proxy_env 
-  enabled: false
-  output: Curl or wget run with disallowed HTTP_PROXY environment variable (env=%proc.env evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_incubating, host, container, users, mitre_execution, T1204]
-
-# In some environments, any attempt by a interpreted program (perl,
-# python, ruby, etc) to listen for incoming connections or perform
-# outgoing connections might be suspicious. These rules are not
-# enabled by default.
-
-- rule: Interpreted procs inbound network activity
-  desc: > 
-    Any inbound network activity performed by any interpreted program (perl, python, ruby, etc.). While it offers broad coverage and behavioral 
-    insights, operationalizing it effectively requires significant time and might result in a moderate level of noise. Suggesting customizing 
-    this rule to be more specific. For example, you could set it up to alert only for important namespaces after studying their usual behavior.
-  condition: >
-    inbound 
-    and interpreted_procs
-  enabled: false
-  output: Interpreted program received/listened for network traffic (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_sandbox, host, container, network, mitre_exfiltration, TA0011]
-
-- rule: Interpreted procs outbound network activity
-  desc: > 
-    Any outbound network activity performed by any interpreted program (perl, python, ruby, etc.). While it offers broad coverage and behavioral 
-    insights, operationalizing it effectively requires significant time and might result in a moderate level of noise. Suggesting customizing 
-    this rule to be more specific. For example, you could set it up to alert only for important namespaces after studying their usual behavior.
-  condition: >
-    outbound 
-    and interpreted_procs
-  enabled: false
-  output: Interpreted program performed outgoing network connection (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_sandbox, host, container, network, mitre_exfiltration, TA0011]
-
 - list: openvpn_udp_ports
   items: [1194, 1197, 1198, 8080, 9201]
 
@@ -2387,19 +1949,6 @@
 - macro: expected_udp_traffic
   condition: fd.port in (expected_udp_ports)
 
-- rule: Unexpected UDP Traffic
-  desc: > 
-    Detecting UDP traffic on ports other than 53 (DNS) or other commonly used ports. Misusing UDP is a known TTP among attackers. 
-    Monitoring unusual network activity is highly valuable but often generates significant noise, as is the case with this detection.
-  condition: > 
-    inbound_outbound 
-    and fd.l4proto=udp 
-    and not expected_udp_traffic
-  enabled: false
-  output: Unexpected UDP Traffic Seen (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_incubating, host, container, network, mitre_exfiltration, TA0011]
-
 # With the current restriction on system calls handled by falco
 # (e.g. excluding read/write/sendto/recvfrom/etc, this rule won't
 # trigger).
@@ -2438,61 +1987,12 @@
 - macro: user_known_non_sudo_setuid_conditions
   condition: (user.name=root)
 
-# sshd, mail programs attempt to setuid to root even when running as non-root. Excluding here to avoid meaningless FPs
-- rule: Non sudo setuid
-  desc: >
-    Detect attempts to change users through the use of setuid, with exceptions for sudo/su. 
-    The users "root" and "nobody" using setuid on themselves are also excluded, as setuid calls in these cases 
-    typically involve reducing privileges. By setting the setuid bit, an attacker could execute code in a 
-    different user's context, potentially with higher privileges. One drawback is the potential for noise, 
-    as many applications legitimately use this approach.
-  condition: >
-    evt.type=setuid and evt.dir=>
-    and (known_user_in_container or not container)
-    and not (user.name=root or user.uid=0)
-    and not somebody_becoming_themselves
-    and not proc.name in (known_setuid_binaries, userexec_binaries, mail_binaries, docker_binaries,
-                          nomachine_binaries)
-    and not proc.name startswith "runc:"
-    and not java_running_sdjagent
-    and not nrpe_becoming_nagios
-    and not user_known_non_sudo_setuid_conditions
-  output: Unexpected setuid call by non-sudo, non-root program (arg_uid=%evt.arg.uid evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_incubating, host, container, users, mitre_privilege_escalation, T1548.001]
-
 - macro: user_known_user_management_activities
   condition: (never_true)
 
 - macro: chage_list
   condition: (proc.name=chage and (proc.cmdline contains "-l" or proc.cmdline contains "--list"))
 
-- rule: User mgmt binaries
-  desc: >
-    Detect activity by any programs that can manage users, passwords, or permissions (such as login, systemd, usermod, deluser, adduser, 
-    chpasswd, and others). sudo and su are excluded. Activity in containers is also excluded -- some containers create custom users on 
-    top of a base linux distribution at startup. Some innocuous command lines that don't actually change anything are excluded. You might 
-    want to consider applying this rule to container actions as well.
-  condition: >
-    spawned_process 
-    and not container
-    and proc.name in (user_mgmt_binaries) 
-    and not proc.name in (su, sudo, lastlog, nologin, unix_chkpwd)  
-    and not proc.pname in (cron_binaries, systemd, systemd.postins, udev.postinst, run-parts)
-    and not proc.cmdline startswith "passwd -S" 
-    and not proc.cmdline startswith "useradd -D" 
-    and not proc.cmdline startswith "systemd --version" 
-    and not run_by_qualys 
-    and not run_by_sumologic_securefiles 
-    and not run_by_yum 
-    and not run_by_ms_oms 
-    and not run_by_google_accounts_daemon 
-    and not chage_list 
-    and not user_known_user_management_activities
-  output: User management binary command run outside of container (gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_incubating, host, users, software_mgmt, mitre_persistence, T1098]
-
 - list: allowed_dev_files
   items: [
     /dev/null, /dev/stdin, /dev/stdout, /dev/stderr,
@@ -2502,26 +2002,6 @@
 - macro: user_known_create_files_below_dev_activities
   condition: (never_true)
 
-# (we may need to add additional checks against false positives, see:
-# https://bugs.launchpad.net/ubuntu/+source/rkhunter/+bug/86153)
-- rule: Create files below dev
-  desc: > 
-    Detect the creation of files under /dev except for authorized device management programs. This can reveal rootkits hiding 
-    files in /dev. Additionally, consider the "Execution from /dev/shm" rule. The upstream rule already covers some tuning 
-    scenarios that you can further expand upon.
-  condition: >
-    (evt.type = creat or (evt.type in (open,openat,openat2)))
-    and evt.arg.flags contains O_CREAT
-    and fd.directory = /dev
-    and not proc.name in (dev_creation_binaries)
-    and not fd.name in (allowed_dev_files)
-    and not fd.name startswith /dev/tty
-    and not user_known_create_files_below_dev_activities
-  output: File created below /dev by untrusted program (file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: ERROR
-  tags: [maturity_incubating, host, filesystem, mitre_persistence, T1543]
-
-
 # In a local/user rules file, you could override this macro to
 # explicitly enumerate the container images that you want to allow
 # access to EC2 metadata. In this main falco rules file, there isn't
@@ -2533,46 +2013,12 @@
 - macro: ec2_metadata_containers
   condition: (never_true)
 
-# On EC2 instances, 169.254.169.254 is a special IP used to fetch
-# metadata about the instance. It may be desirable to prevent access
-# to this IP from containers.
-- rule: Contact EC2 Instance Metadata Service From Container
-  desc: > 
-    Detects attempts to communicate with the EC2 Instance Metadata Service from a container. This detection is narrowly focused 
-    and might not apply to your environment. In addition, it could generate noise and require fine-tuning.
-  condition: > 
-    outbound 
-    and container
-    and fd.sip="169.254.169.254" 
-    and not ec2_metadata_containers
-  output: Outbound connection to EC2 instance metadata service (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  enabled: false
-  tags: [maturity_incubating, network, aws, container, mitre_credential_access, T1552.005]
-
-
 # This rule is not enabled by default, since this rule is for cloud environment(GCP, AWS and Azure) only.
 # You can filter the container that you want to allow access to metadata by overwriting user_known_metadata_access macro.
 
 - macro: user_known_metadata_access
   condition: (k8s.ns.name = "kube-system")
 
-# On GCP, AWS and Azure, 169.254.169.254 is a special IP used to fetch
-# metadata about the instance. The metadata could be used to get credentials by attackers.
-- rule: Contact cloud metadata service from container
-  desc: > 
-    Detects attempts to communicate with the Cloud Instance Metadata Service from a container. This detection is narrowly focused 
-    and might not apply to your environment. In addition, it could generate noise and require fine-tuning.
-  condition: > 
-    outbound 
-    and container 
-    and fd.sip="169.254.169.254" 
-    and not user_known_metadata_access
-  enabled: true
-  output: Outbound connection to cloud instance metadata service (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_incubating, network, container, mitre_discovery, T1565]
-
 # Containers from IBM Cloud
 - list: ibm_cloud_containers
   items:
@@ -2637,23 +2083,6 @@
 - macro: nodeport_containers
   condition: (never_true)
 
-- rule: Unexpected K8s NodePort Connection
-  desc: > 
-    Detect attempts to utilize K8s NodePorts from a container. K8s NodePorts are accessible on the eth0 interface of 
-    each node, and they facilitate external traffic into a Kubernetes cluster. Attackers could misuse them for 
-    unauthorized access. The rule uses default port ranges, but check for custom ranges and make necessary adjustments. 
-    Also, consider tuning this rule as needed.
-  condition: > 
-    inbound_outbound 
-    and container 
-    and fd.sport >= 30000 
-    and fd.sport <= 32767 
-    and not nodeport_containers
-  enabled: false
-  output: Unexpected K8s NodePort Connection (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_sandbox, network, k8s, container, mitre_persistence, T1205.001, NIST_800-53_AC-6]
-
 - list: network_tool_binaries
   items: [nc, ncat, netcat, nmap, dig, tcpdump, tshark, ngrep, telnet, mitmproxy, socat, zmap]
 
@@ -2677,24 +2106,6 @@
     and (container.image.repository = "registry.k8s.io/kube-proxy"
     or container.image.repository = "k8s.gcr.io/kube-proxy"))
 
-- rule: Launch Package Management Process in Container
-  desc: > 
-    Detect package management processes executed within containers. An excellent auditing rule to monitor general drifts 
-    in containers. Particularly useful for newer rules like "Drop and execute new binary in container" during incident 
-    response investigations. This helps identify common anti-patterns of ad-hoc debugging. Simultaneously, to maintain 
-    optimal hygiene, it's recommended to prevent container drifts and instead opt for redeploying new containers.
-  condition: >
-    spawned_process
-    and container
-    and user.name != "_apt"
-    and package_mgmt_procs
-    and not package_mgmt_ancestor_procs
-    and not user_known_package_manager_in_container
-    and not pkg_mgmt_in_kube_proxy
-  output: Package management process launched in container (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: ERROR
-  tags: [maturity_incubating, container, process, software_mgmt, mitre_persistence, T1505]
-
 - rule: Netcat Remote Code Execution in Container
   desc: > 
     Netcat Program runs inside container that allows remote code execution and may be utilized 
@@ -2718,35 +2129,6 @@
 - macro: user_known_network_tool_activities
   condition: (never_true)
 
-- rule: Launch Suspicious Network Tool in Container
-  desc: >
-    Detect network tools (like netcat, nmap, tcpdump, socat, and more) launched within containers without any additional filters. 
-    This serves as a valuable general detection, but it's recommended to invest engineering effort to fine-tune it and prevent a 
-    high volume of legitimate logs. This rule complements the more specific "Netcat Remote Code Execution in Container" rule.
-  condition: >
-    spawned_process 
-    and container 
-    and network_tool_procs 
-    and not user_known_network_tool_activities
-  output: Network tool launched in container (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_incubating, container, network, process, mitre_execution, T1059]
-
-- rule: Launch Suspicious Network Tool on Host
-  desc: >
-    Detect network tools (like netcat, nmap, tcpdump, socat, and more) launched within containers without any additional filters. 
-    This serves as a valuable general detection, but it's recommended to invest engineering effort to fine-tune it and prevent a 
-    high volume of legitimate logs. The host equivalent of "Launch Suspicious Network Tool in Container.".
-  condition: >
-    spawned_process 
-    and not container 
-    and network_tool_procs 
-    and not user_known_network_tool_activities
-  enabled: false
-  output: Network tool launched on host (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags)
-  priority: NOTICE
-  tags: [maturity_incubating, host, network, process, mitre_execution, T1059]
-
 - list: grep_binaries
   items: [grep, egrep, fgrep]
 
@@ -2876,20 +2258,6 @@
 - macro: var_lib_docker_filepath
   condition: (evt.arg.name startswith /var/lib/docker or fd.name startswith /var/lib/docker)
 
-- rule: Delete or rename shell history
-  desc: > 
-    Detect shell history deletion, frequently used by unsophisticated adversaries to eliminate evidence. 
-    Note that it can also trigger when exiting a Terminal shell, such as with `kubectl exec`, which 
-    may introduce some noise.
-  condition: >
-    (modify_shell_history or truncate_shell_history) 
-    and not var_lib_docker_filepath 
-    and not proc.name in (docker_binaries)
-  output: Shell history deleted or renamed (file=%fd.name name=%evt.arg.name path=%evt.arg.path oldpath=%evt.arg.oldpath evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority:
-    WARNING
-  tags: [maturity_incubating, host, container, process, filesystem, mitre_defense_evasion, T1070]
-
 - list: user_known_chmod_applications
   items: [hyperkube, kubelet, k3s-agent]
 
@@ -2899,24 +2267,6 @@
 - macro: user_known_set_setuid_or_setgid_bit_conditions
   condition: (never_true)
 
-- rule: Set Setuid or Setgid bit
-  desc: >
-    This rule is focused on detecting the use of setuid or setgid bits set via chmod. These bits, when set for an application, 
-    result in the application running with the privileges of the owning user or group. By enabling the setuid or setgid bits, 
-    an attacker could run code in a different user's context, possibly with elevated privileges. However, there's a trade-off 
-    with noise, given that numerous applications legitimately run chmod. This rule is related to the "Non sudo setuid" rule.
-  condition: >
-    chmod 
-    and (evt.arg.mode contains "S_ISUID" or evt.arg.mode contains "S_ISGID")
-    and not proc.name in (user_known_chmod_applications)
-    and not exe_running_docker_save
-    and not user_known_set_setuid_or_setgid_bit_conditions
-  enabled: false
-  output: Setuid or setgid bit is set via chmod (fd=%evt.arg.fd filename=%evt.arg.filename mode=%evt.arg.mode evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority:
-    NOTICE
-  tags: [maturity_incubating, host, container, process, users, mitre_privilege_escalation, T1548.001]
-
 - list: exclude_hidden_directories
   items: [/root/.cassandra]
 
@@ -2924,24 +2274,6 @@
 - macro: user_known_create_hidden_file_activities
   condition: (never_true)
 
-- rule: Create Hidden Files or Directories
-  desc: > 
-    Detecting hidden files or directories creation can serve as an auditing rule to track general system changes. 
-    Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful 
-    profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system 
-    changes, including compliance-related cases.
-  condition: >
-    ((modify and evt.arg.newpath contains "/.") or
-     (mkdir and evt.arg.path contains "/.") or
-     (open_write and evt.arg.flags contains "O_CREAT" and fd.name contains "/." and not fd.name pmatch (exclude_hidden_directories))) 
-    and not user_known_create_hidden_file_activities
-    and not exe_running_docker_save
-  enabled: false
-  output: Hidden file or directory created (file=%fd.name newpath=%evt.arg.newpath evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority:
-    NOTICE
-  tags: [maturity_sandbox, host, container, filesystem, mitre_defense_evasion, T1564.001]
-
 - list: remote_file_copy_binaries
   items: [rsync, scp, sftp, dcp]
 
@@ -2953,19 +2285,6 @@
 - macro: user_known_remote_file_copy_activities
   condition: (never_true)
 
-- rule: Launch Remote File Copy Tools in Container
-  desc: > 
-    Detect remote file copy tools (like rsync, scp, sftp, dcp) launched within a container, potentially indicating data 
-    exfiltration. Suggest refining this rule to accommodate legitimate use cases.
-  condition: >
-    spawned_process
-    and container
-    and remote_file_copy_procs
-    and not user_known_remote_file_copy_activities
-  output: Remote file copy tool launched in container (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_incubating, container, network, process, mitre_exfiltration, T1020]
-
 - rule: Create Symlink Over Sensitive Files
   desc: > 
     Detect symlinks created over a curated list of sensitive files or subdirectories under /etc/ or 
@@ -3085,35 +2404,6 @@
 - macro: trusted_images_query_miner_domain_dns
   condition: (container.image.repository in (falco_containers))
 
-# The rule is disabled by default.
-# Note: falco will send DNS request to resolve miner pool domain which may trigger alerts in your environment.
-- rule: Detect outbound connections to common miner pool ports
-  desc: > 
-    Miners usually connect to miner pools using standard ports, and this rule flags such activity. Important: Falco currently sends DNS 
-    requests to resolve miner pool domains, which could trigger other alerts. Prior to enabling this rule, it's advised to ensure whether 
-    this is acceptable for your environment. This rule is specifically disabled for that reason.
-  condition: > 
-    net_miner_pool 
-    and not trusted_images_query_miner_domain_dns
-  enabled: false
-  output: Outbound connection to IP/Port flagged by https://cryptoioc.ch (ip=%fd.rip connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: CRITICAL
-  tags: [maturity_sandbox, host, container, network, mitre_impact, T1496]
-
-- rule: Detect crypto miners using the Stratum protocol
-  desc: > 
-    Miners commonly specify the mining pool to connect to using a URI that starts with "stratum+tcp". However, this rule is highly specific to 
-    this technique, and matching command-line arguments can generally be bypassed quite easily.
-  condition: > 
-    spawned_process 
-    and (proc.cmdline contains "stratum+tcp" or 
-         proc.cmdline contains "stratum2+tcp" or 
-         proc.cmdline contains "stratum+ssl" or 
-         proc.cmdline contains "stratum2+ssl")
-  output: Possible miner running (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: CRITICAL
-  tags: [maturity_sandbox, host, container, process, mitre_impact, T1496]
-
 - list: k8s_client_binaries
   items: [docker, kubectl, crictl]
 
@@ -3141,20 +2431,6 @@
 - macro: user_known_k8s_client_container_parens
   condition: (user_known_k8s_client_container)
 
-- rule: The docker client is executed in a container
-  desc: > 
-    Detect the execution of a Kubernetes client tool (like docker, kubectl, crictl) within a container, which is typically not expected behavior. 
-    Although this rule targets container workloads, monitoring the use of tools like crictl on the host over interactive access could also be 
-    valuable for broader auditing objectives. The rule name is outdated and somewhat misleading when considering the expanded use cases now involved.
-  condition: > 
-    spawned_process 
-    and container 
-    and not user_known_k8s_client_container_parens 
-    and proc.name in (k8s_client_binaries)
-  output: Docker or kubernetes client executed in container (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: WARNING
-  tags: [maturity_sandbox, container, mitre_execution, T1610]
-
 - list: user_known_packet_socket_binaries
   items: []
 
@@ -3182,28 +2458,6 @@
     fd.ip = "0.0.0.0" or
     fd.net = "127.0.0.0/8")
 
-# # The rule is disabled by default.
-# # How to test:
-# # Add 'default' to namespace_scope_network_only_subnet
-# # Run:
-# kubectl run --generator=run-pod/v1 -n default -i --tty busybox --image=busybox --rm -- wget google.com -O /var/google.html
-# # Check logs running
-
-- rule: Network Connection outside Local Subnet
-  desc: > 
-    Detect network traffic (inbound or outbound) from a container to a destination outside the local subnet. 
-    To operationalize this rule, profile your environment and update the template macro namespace_scope_network_only_subnet. 
-    Customizing network-related rules usually demands substantial engineering effort to ensure their functionality.
-  condition: >
-    inbound_outbound 
-    and container 
-    and k8s.ns.name in (namespace_scope_network_only_subnet) 
-    and not network_local_subnet 
-  enabled: false
-  output: Network connection outside local subnet (fd_rip_name=%fd.rip.name fd_lip_name=%fd.lip.name fd_cip_name=%fd.cip.name fd_sip_name=%fd.sip.name connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: WARNING
-  tags: [maturity_incubating, container, network, mitre_discovery, T1046, PCI_DSS_6.4.2]
-
 - list: allowed_image
   items: [] # add image to monitor, i.e.: bitnami/nginx
 
@@ -3213,36 +2467,6 @@
 - list: authorized_server_port
   items: [] # add port to allow, i.e.: 80
 
-# # How to test:
-# kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster"
-# kubectl expose deployment nginx-app --port=80 --name=nginx-http --type=LoadBalancer
-# # On minikube:
-# minikube service nginx-http
-# # On general K8s:
-# kubectl get services
-# kubectl cluster-info
-# # Visit the Nginx service and port, should not fire.
-# # Change rule to different port, then different process name, and test again that it fires.
-
-- rule: Outbound or Inbound Traffic not to Authorized Server Process and Port
-  desc: > 
-    Detect traffic to an unauthorized server process and port within pre-defined containers. 
-    This rule absolutely requires profiling your environment beforehand and also necessitates adjusting the list of containers 
-    to which this rule will be applied. The current expression logic will never evaluate to true unless the list is populated. 
-    Network-based rules are extremely crucial in any security program, as they can often provide the only definitive evidence. 
-    However, effectively operationalizing them can be challenging due to the potential for noise. Notably, this rule is challenging 
-    to operationalize.
-  condition: >
-    inbound_outbound 
-    and container 
-    and container.image.repository in (allowed_image) 
-    and not proc.name in (authorized_server_binary) 
-    and not fd.sport in (authorized_server_port)
-  enabled: false
-  output: Network connection outside authorized port and binary (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: WARNING
-  tags: [maturity_deprecated, container, network, mitre_discovery, TA0011, NIST_800-53_CM-7]
-
 - macro: user_known_stand_streams_redirect_activities
   condition: (never_true)
 
@@ -3290,92 +2514,12 @@
 - macro: user_known_container_drift_activities
   condition: (never_true)
 
-- rule: Container Drift Detected (chmod)
-  desc: > 
-    Detect new executables created within a container as a result of chmod. While this detection can generate significant noise, chmod 
-    usage is frequently linked to dropping and executing malicious implants. The newer rule "Drop and execute new binary in container" 
-    provides more precise detection of this TTP using unambiguous kernel signals. It is recommended to use the new rule. However, this 
-    rule might be more relevant for auditing if applicable in your environment, such as when chmod is used on files within the /tmp folder.
-  condition: >
-    chmod 
-    and container 
-    and evt.rawres>=0 
-    and ((evt.arg.mode contains "S_IXUSR") or
-         (evt.arg.mode contains "S_IXGRP") or
-         (evt.arg.mode contains "S_IXOTH"))
-    and not runc_writing_exec_fifo 
-    and not runc_writing_var_lib_docker 
-    and not user_known_container_drift_activities 
-  enabled: false
-  output: Drift detected (chmod), new executable created in a container (filename=%evt.arg.filename name=%evt.arg.name mode=%evt.arg.mode evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: ERROR
-  tags: [maturity_sandbox, container, process, filesystem, mitre_execution, T1059]
-
-# ****************************************************************************
-# * "Container Drift Detected (open+create)" requires FALCO_ENGINE_VERSION 6 *
-# ****************************************************************************
-- rule: Container Drift Detected (open+create)
-  desc: >
-    Detect new executables created within a container as a result of open+create. The newer rule "Drop and execute new binary in container" 
-    provides more precise detection of this TTP using unambiguous kernel signals. It is recommended to use the new rule. 
-  condition: >
-    evt.type in (open,openat,openat2,creat) 
-    and evt.rawres>=0
-    and evt.is_open_exec=true 
-    and container 
-    and not runc_writing_exec_fifo 
-    and not runc_writing_var_lib_docker 
-    and not user_known_container_drift_activities 
-  enabled: false
-  output: Drift detected (open+create), new executable created in a container (filename=%evt.arg.filename name=%evt.arg.name mode=%evt.arg.mode evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: ERROR
-  tags: [maturity_sandbox, container, process, filesystem, mitre_execution, T1059]
-
 - list: c2_server_ip_list
   items: []
 
 - list: c2_server_fqdn_list
   items: []
 
-# For example, you can fetch a list of IP addresses and FQDN on this website:
-# https://feodotracker.abuse.ch/downloads/ipblocklist_recommended.json.
-# Use Falco HELM chart to update (append) the c2 server lists with your values.
-# See an example below.
-#
-#  ```yaml
-#  # values.yaml Falco HELM chart file
-#  [...]
-#  customRules:
-#    c2-servers-list.yaml: |-
-#      - list: c2_server_ip_list
-#        append: true
-#        items: 
-#        - "'51.178.161.32'"
-#        - "'46.101.90.205'"
-#        
-#      - list: c2_server_fqdn_list
-#        append: true
-#        items: 
-#        - "srv-web.ffconsulting.com"
-#        - "57.ip-142-44-247.net"
-#  ```
-
-- rule: Outbound Connection to C2 Servers
-  desc: > 
-    Detect outbound connections to command and control servers using a list of IP addresses and fully qualified domain names (FQDNs).
-    This rule absolutely requires profiling your environment beforehand and also necessitates adjusting the template lists. The current 
-    expression logic will never evaluate to true unless the lists are populated. Network-based rules are extremely crucial in any 
-    security program, as they can often provide the only definitive evidence. However, effectively operationalizing them can be challenging 
-    due to the potential for noise. Notably, this rule is challenging to operationalize.
-  condition: >
-    outbound 
-    and ((fd.sip in (c2_server_ip_list)) or
-         (fd.sip.name in (c2_server_fqdn_list)))
-  output: Outbound connection to C2 server (c2_domain=%fd.sip.name c2_addr=%fd.sip connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: WARNING
-  enabled: false
-  tags: [maturity_deprecated, host, container, network, mitre_command_and_control, TA0011]
-
 - list: allowed_container_images_loading_kernel_module
   items: []
 
@@ -3399,41 +2543,6 @@
 - macro: user_known_run_as_root_container
   condition: (container.image.repository in (run_as_root_image_list))
 
-# The rule is disabled by default and should be enabled when non-root container policy has been applied.
-# Note the rule will not work as expected when usernamespace is applied, e.g. userns-remap is enabled.
-- rule: Container Run as Root User
-  desc: > 
-    Container detected running as the root user. This should be taken into account especially when policies disallow containers from running with 
-    root user privileges. Note that a root user in containers doesn't inherently possess extensive power, as modern container environments define 
-    privileges through Linux capabilities. To learn more, check out the rule "Launch Privileged Container".
-  condition: > 
-    spawned_process 
-    and container 
-    and proc.vpid=1 
-    and user.uid=0 
-    and not user_known_run_as_root_container
-  enabled: false
-  output: Container launched with root user privilege (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: INFO
-  tags: [maturity_sandbox, container, process, users, mitre_execution, T1610]
-
-# This rule helps detect CVE-2021-3156:
-# A privilege escalation to root through heap-based buffer overflow
-- rule: Sudo Potential Privilege Escalation
-  desc: > 
-    Affecting sudo (<= 1.9.5p2), there's a privilege escalation vulnerability. By executing sudo using the sudoedit -s or sudoedit -i command with a 
-    command-line argument that ends with a single backslash character, an unprivileged user can potentially escalate privileges to root. This rule is 
-    highly specific and might be bypassed due to potential issues with string matching on command line arguments.
-  condition: > 
-    spawned_process 
-    and user.uid != 0 
-    and (proc.name=sudoedit or proc.name = sudo) 
-    and (proc.args contains -s or proc.args contains -i or proc.args contains --login) 
-    and (proc.args contains "\ " or proc.args endswith \)
-  output: Detect Sudo Privilege Escalation Exploit (CVE-2021-3156) (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: CRITICAL
-  tags: [maturity_sandbox, host, container, filesystem, users, mitre_privilege_escalation, T1548.003]
-
 - rule: Debugfs Launched in Privileged Container
   desc: > 
     Detect file system debugger debugfs launched inside a privileged container which might lead to container escape. 
@@ -3463,40 +2572,9 @@
 - macro: user_known_mount_in_privileged_containers
   condition: (never_true)
 
-- rule: Mount Launched in Privileged Container
-  desc: > 
-    Detect filesystem mounts (using the mount binary) within a privileged container. Due to the elevated privileges, 
-    this action could be one of the TTPs used in an attempt to escape from a container to the host. This type of action 
-    is often preceded by reconnaissance activities, for which you can also create custom rules.
-  condition: >
-    spawned_process 
-    and container
-    and container.privileged=true
-    and proc.name=mount
-    and not mount_info
-    and not known_gke_mount_in_privileged_containers
-    and not known_aks_mount_in_privileged_containers
-    and not user_known_mount_in_privileged_containers
-  output: Mount was executed inside a privileged container (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: WARNING
-  tags: [maturity_incubating, container, cis, filesystem, mitre_privilege_escalation, T1611]
-
 - list: user_known_userfaultfd_processes
   items: []
 
-- rule: Unprivileged Delegation of Page Faults Handling to a Userspace Process
-  desc: > 
-    Detect a successful unprivileged userfaultfd syscall, which could serve as an attack primitive for exploiting other vulnerabilities. 
-    To fine-tune this rule, consider using the template list "user_known_userfaultfd_processes".
-  condition: >
-    evt.type = userfaultfd 
-    and user.uid != 0 
-    and (evt.rawres >= 0 or evt.res != -1) 
-    and not proc.name in (user_known_userfaultfd_processes)
-  output: An userfaultfd syscall was successfully executed by an unprivileged user (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: CRITICAL
-  tags: [maturity_sandbox, host, container, process, mitre_defense_evasion, TA0005]
-
 - list: ingress_remote_file_copy_binaries
   items: [wget]
 
@@ -3515,36 +2593,6 @@
               proc.cmdline contains " -O " or
               proc.cmdline contains " --remote-name "))
 
-- rule: Launch Ingress Remote File Copy Tools in Container
-  desc: > 
-    Detect ingress remote file copy tools (such as curl or wget) launched inside containers. This rule can be 
-    considered a valuable auditing tool, but it has the potential to generate notable noise and requires careful 
-    profiling before full operationalization.
-  condition: >
-    spawned_process 
-    and container 
-    and (ingress_remote_file_copy_procs or curl_download) 
-    and not user_known_ingress_remote_file_copy_activities
-  output: Ingress remote file copy tool launched in container (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: NOTICE
-  tags: [maturity_incubating, container, network, process, mitre_command_and_control, TA0011]
-
-# This rule helps detect CVE-2021-4034:
-# A privilege escalation to root through memory corruption
-- rule: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034)
-  desc: > 
-    This rule detects attempts to exploit a privilege escalation vulnerability in Polkit's pkexec. Through the execution of specially 
-    crafted code, a local user can exploit this weakness to attain root privileges on a compromised system. This rule is highly 
-    specific in its scope.
-  condition:
-    spawned_process 
-    and user.uid != 0 
-    and proc.name=pkexec 
-    and proc.args = ''
-  output: Detect Polkit pkexec Local Privilege Escalation Exploit (CVE-2021-4034) (args=%proc.args evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: CRITICAL
-  tags: [maturity_sandbox, host, container, process, users, mitre_privilege_escalation, TA0004]
-
 - rule: Detect release_agent File Container Escapes
   desc: > 
     Detect an attempt to exploit a container escape using release_agent file. 
@@ -3565,57 +2613,15 @@
 - macro: java_network_read
   condition: (evt.type=recvfrom and fd.type in (ipv4, ipv6) and proc.exe endswith java)
 
-- rule: Java Process Class File Download
-  desc: > 
-    Detecting a Java process downloading a class file which could indicate a successful exploit of the log4shell Log4j vulnerability (CVE-2021-44228). 
-    This rule is highly specific in its scope.
-  condition: >
-    java_network_read 
-    and evt.buffer bcontains cafebabe
-  output: Java process class file download (server_ip=%fd.sip server_port=%fd.sport connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: CRITICAL
-  enabled: false
-  tags: [maturity_sandbox, host, container, process, mitre_initial_access, T1190]
-
 - list: docker_binaries
   items: [docker, dockerd, containerd-shim, "runc:[1:CHILD]", pause, exe, docker-compose, docker-entrypoi, docker-runc-cur, docker-current, dockerd-current]
 
 - macro: docker_procs
   condition: proc.name in (docker_binaries)
 
-- rule: Modify Container Entrypoint
-  desc: > 
-    This rule detect an attempt to write on container entrypoint symlink (/proc/self/exe). Possible CVE-2019-5736 Container Breakout exploitation attempt. 
-    This rule has a more narrow scope.
-  condition: >
-    open_write 
-    and container 
-    and (fd.name=/proc/self/exe or fd.name startswith /proc/self/fd/) 
-    and not docker_procs 
-    and not proc.cmdline = "runc:[1:CHILD] init"
-  enabled: false
-  output: Detect Potential Container Breakout Exploit (CVE-2019-5736) (file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: WARNING
-  tags: [maturity_sandbox, container, filesystem, mitre_initial_access, T1611]
-
 - list: known_binaries_to_read_environment_variables_from_proc_files
   items: [scsi_id, argoexec]
 
-- rule: Read environment variable from /proc files
-  desc: > 
-    An attempt to read process environment variables from /proc files. The consequences are akin to accessing traditional 
-    sensitive files, as sensitive data, including secrets, might be stored in environment variables. Understanding your 
-    environment, such as identifying critical namespaces, and incorporating extra filtering statements to alert exclusively 
-    for those, can enhance the rule's effectiveness.
-  condition: >
-    open_read 
-    and container 
-    and (fd.name glob /proc/*/environ)
-    and not proc.name in (known_binaries_to_read_environment_variables_from_proc_files)
-  output: Environment variables were retrieved from /proc files (file=%fd.name gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
-  priority: WARNING
-  tags: [maturity_incubating, container, filesystem, process, mitre_discovery, T1083]
-
 - list: known_ptrace_binaries
   items: []
 
@@ -3721,7 +2727,3 @@
   output: Executing binary not part of base image (proc_exe=%proc.exe proc_sname=%proc.sname gparent=%proc.aname[2] proc_exe_ino_ctime=%proc.exe_ino.ctime proc_exe_ino_mtime=%proc.exe_ino.mtime proc_exe_ino_ctime_duration_proc_start=%proc.exe_ino.ctime_duration_proc_start proc_cwd=%proc.cwd container_start_ts=%container.start_ts evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
   priority: CRITICAL
   tags: [maturity_stable, container, process, mitre_persistence, TA0003, PCI_DSS_11.5.1]
-
-# Application rules have moved to application_rules.yaml. Please look
-# there if you want to enable them by adding to
-# falco_rules.local.yaml.