Supported Services and Risks

Panoptica continually scans your cloud resources for potential risks, security issues and vulnerabilities across dozens of key services. This catalog provides a complete list of the services Panoptica scans across multiple cloud providers and platforms, and the hundreds of risks Panoptica can detect in those services. The results of these scans show up in different aspects of the Panoptica platform:

To view the services Panoptica has identified in your environment, see Cloud Inventory.
To view the risks Panoptica has identified, see Security Posture.
To view those risks prioritized and contextualized, see Attack Paths.

The catalog is sorted by provider, service name, and category. In Chrome or Edge, use the Table of Contents to the right to navigate to the information you're looking for. Firefox and Safari, however, are unable to expand a section to display an anchor link within, like Chrome and Edge can. If you're using Firefox or Safari, click the cloud provider header in the Table of Contents (AWS, Azure, GCP, etc.), then select the service you want to expand in the main section.

Amazon Web Services (AWS) - click to collapse

Amazon Web Services (AWS)

Click on a service name below to view a table of the risks Panoptica detects in AWS, along with brief descriptions and attack scenarios.

AWS Certificate Manager

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	ACM Certificate Without Minimum Of 2048-bit Key For RSA Certificate	An ACM certificate that does not use a minimum of 2048-bit key for RSA certificate.	"A key length of 1024 bit is not considered secure, as it can be cracked using brute-force methods. Upgrade your certificates to 2048-bit or 4096-bit RSA certificates which are using stronger encryption algorithms."
Neglected Resource	ACM Certificate Expires In 30 Days	An ACM certificate is going to expire in 30 days.	It is not a best practice to have an expired certificate. An expired certificate can be accidentally deployed to another resource, leading to application errors and credibility damage. Renew the certificate as soon as possible.
Neglected Resource	ACM Certificate Pending Validation	An ACM certificate with 'PENDING_VALIDATION' status.	When an ACM certificate is not validted within 72 hours, it becomes invalid and you have to create a new certificate request.
Neglected Resource	Expired ACM Certificate	An expired ACM certificate.	It is not a best practice to have an expired certificate. An expired certificate can cause an accidental deployment to another resource, leading to application errors and credibility damage.
Neglected Resource	Invalid ACM Certificate	An ACM certificate with 'FAILED' or 'VALIDATION_TIMED_OUT' status.	It is not a best practice to have invalid certificates. Invalid certificates should be deleted.
Neglected Resource	Unused ACM Certificate	Unused ACM Certificate	It is not a best practice to have unused certificates. Unused certificates should be used or removed.

Amazon CloudFront

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	CloudFront Distribution Lacking WAF Protection	This risk highlights a CloudFront distribution that is not protected by a Web Application Firewall (WAF). Without WAF protection, your distribution may be vulnerable to common web exploits that could affect availability or compromise security. To enhance your distribution's security, it's recommended to attach a properly configured WAF to your CloudFront distribution.	"A WAF helps protect web applications by filtering and monitoring traffic. It usually protects web applications from attacks such as cross-site forgery, cross-site-scripting (XSS), file inclusion, and SQL injection. An attacker can use this opportunity to attack your application."
Insecure Configurations	CloudFront Distribution Permitting Insecure HTTP Connections	This risk underscores a CloudFront distribution that allows insecure HTTP connections. Such connections could expose your data to potential risks during transmission. It's advised to enforce secure HTTPS connections for your CloudFront distribution to ensure the security and integrity of your data.	An attacker can gain access to traffic between your CloudFront distribution and the application viewers.
Insecure Configurations	CloudFront Distribution with Logging Disabled	This risk signifies a CloudFront distribution that has logging disabled. Without logging, it can be challenging to monitor and troubleshoot your distribution's activity. It's highly recommended to enable and properly configure logging for your CloudFront distribution to ensure effective operations and prompt issue resolution.	CloudFront distribution logging is used to track all the requests. It is necessary for investigating activities and for auditing purposes.
Insecure Configurations	CloudFront Operating with Unencrypted Origin Server Connection	This risk identifies a CloudFront distribution configured to operate with an unencrypted connection to the origin server. Such a configuration can expose your data to unnecessary risks during transmission. It's highly advised to secure the connection to your origin server with encryption, such as HTTPS, to uphold the integrity and confidentiality of your data.	An attacker can gain access to traffic between your CloudFront distribution and an origin server.
Insecure Configurations	CloudFront With Insecure TLS Ciphers	A CloudFront distribution that does not use secure TLS (Transport Layer Security) protocol versions.	It is recommended to use the latest version of TLS if possible. Older versions (prior to TLS 1.2) may be deprecated or may contain known vulnerabilities that an attacker can use.

Amazon DocumentDB

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	DocumentDB Audit Logs Export Disabled	DocumentDB cluster without export audit logs to Cloudwatch.	Without comprehensive auditing, there's a higher risk of undetected security breaches or unauthorized access to your system.
Insecure Configurations	DocumentDB Cluster has Short Retention Period	DocumentDB cluster has less than 7 days backup retention period.	A backup retention period ensures that you have a reliable copy of your data in case of accidental deletion, corruption, or other data loss events.
Insecure Configurations	DocumentDB without Deletion Protection	Deletion protection is disabled.	Disabling deletion protection in a DocumentDB can introduce several security risks. Deletion protection is a feature that prevents accidental or unauthorized data deletions, and disabling it can make your database more vulnerable to various threats.
Insecure Configurations	DocumentDB Without Storage Encryption	An attacker with access to the DocumentDB can access sensitive data stored in the DB.	This risk indicates an Amazon DocumentDB that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.

Amazon DynamoDB

Category	Risk Name	Description	Attack Scenario
Neglected Resource	DynamoDB Table Without Continuous Backup	A DynamoDB table without continuous backups for the point-in-time recovery feature.	It is a best practice to enable continuous backups for your DynamoDB tables. DynamoDB continuous backups, powered by Point-in-time Recovery (PITR) feature, will help you protect your DynamoDB data against accidental writes, deletes, or any loss of data.

Amazon EC2

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Default Security Group Assignment	The EC2 instance uses the default Security Group.	An attacker might exploit misconfuguration or wide allowed outbound IP range to obtain network access to the EC2 instance.
Insecure Configurations	EC2 Classic Instance Not Operating Within a VPC	This risk underscores an EC2 Classic instance that is not operating within a Virtual Private Cloud (VPC). Operating outside of a VPC may expose your EC2 instance to unnecessary security risks and limit control over network configuration. It's strongly advised to migrate your EC2 Classic instances to a VPC, providing an additional layer of security and increased control over networking aspects, to bolster your system security.	Current workloads might be interrupted.
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf.
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0.
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.
Public Exposure	Public AWS EBS Snapshot	Publicly shared Elastic Block Store (EBS) volume snapshot with all other AWS accounts.	An attacker can use the public shared EBS snapshot in its own account and potentially expose sensitive data.
Neglected Resource	Unassociated Elastic IP Address	The Elastic IP is unused, not associated with any resource in the cloud environment.	An attacker might leverage the neglected Elastic IP to bypass security mechanisms or direct traffic to a malicious server.
Public Exposure	Public AWS AMI	Publicly shared AWS AMI with all other AWS accounts.	An attacker can attach the public shared AMI to a machine in the attacker's AWS account and inspect the image.

Amazon Elastic Container Registry

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Private ECR Repository Allows Anonymous Users To Pull Images	Private ECR repository allowing anyone to pull images.	An attacker can pull images from a private repository.
Insecure Configurations	Private ECR Repository Allows Anonymous Users To Push Images	Private ECR repository with permissions to push images.	An attacker can push a malicious image to the repository.
Insecure Configurations	Private ECR Repository Without KMS Key	Private ECR repository without KMS encryption.	KMS provides more control over the repository encryption.
Insecure Configurations	Public ECR Repository Allows Anonymous Users Access	Public ECR repository enables any user to perform ECR actions.
Insecure Configurations	Public ECR Repository Allows Anonymous Users To Push Images	Public ECR repository with permissions to push images.	An attacker can push a malicious image to the repository.

Amazon ECS

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	"When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. \nThe metadata information is available by making a request to the IP address of 169.254.169.254. \nThe current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf."
Insecure Configurations	ECS Container Operating in Elevated Privilege Mode	This risk signifies an ECS container that's operating in a privileged mode. When a container is run in privileged mode, it holds potential access to all devices on the host system, thereby posing a significant security risk. This unrestricted access could lead to unauthorized activities or data breaches if the container were to be compromised. It's highly recommended to review the necessity of privileged mode for this container. If not required, a prompt action to modify the container's access privileges is advised to uphold system security and integrity.	An attacker with access to the container can gain unauthorized access to other resources in the enviornment.
Insecure Configurations	ECS Container with Elevated System Administrator Capabilities	This risk underscores an ECS container configured with CAP_SYS_ADMIN capabilities. This configuration grants the container nearly unrestricted system-level permissions equivalent to the root user on the host, which can significantly amplify the potential impact of a security breach if the container is compromised. It's essential to reassess the necessity of such elevated privileges. If these superuser capabilities are not necessary for the container's operations, it is strongly advised to reduce its permissions promptly, thereby bolstering system security and reducing potential attack vectors.	"`CAP_SYS_ADMIN` is equivalent to root. An attacker with access to the container can gain root privileges."
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	"This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0."
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.

Amazon EKS

Category	Risk Name	Description	Attack Scenario
Credentials Exposure	EKS Cluster Operating Without Secrets Encryption	This risk identifies an EKS cluster that is operating without secrets encryption. The absence of encryption could expose your sensitive information and make it vulnerable to unauthorized access or breaches. It's strongly advised to enable secrets encryption for your EKS cluster to enhance the protection of sensitive data. OWASP K08:2022 Secrets Management Failures	By default, Kubernetes secrets are stored in Base64 encoding in the etcd. An attacker with access to the cluster etcd, will be able to use the stored secrets and compromise your cluster.
Insecure Configurations	EKS Cluster Running With Logging Configurations Disabled	This risk signifies an EKS cluster that is operating with disabled logging configurations. Proper logging provides crucial insights into your system's operations and potential issues. A disabled logging configuration could hinder problem detection and system monitoring. It's highly recommended to enable and configure appropriate logging for your EKS cluster to ensure efficient operations and issue resolution. OWASP K05:2022 Inadequate Logging and Monitoring	Logging provides audit and diagnostic logs directly from EKS to CloudWatch Logs in your account. These logs make it easy for you to secure and run your clusters.
Public Exposure	Publicly Accessible EKS API Server Endpoint	This risk underscores an EKS API Server Endpoint that is publicly accessible. Public access to your API Server Endpoint could potentially expose your system to unauthorized access and possible security threats. It's advised to review and restrict access to your EKS API Server Endpoint, limiting it to necessary IP ranges or secure VPN connections, to bolster system security. OWASP K09:2022 Misconfigured Cluster Components	An attacker can access the Kubernetes API server from external IP address and use it as an optional entry point into the environment.

Amazon EFS

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Default Security Group
Insecure Configurations	Security Group with Inappropriately Configured CIDR IP	This risk highlights a Security Group with a misconfigured CIDR IP, which may expose your resources to unintended networks, leading to potential unauthorized access. A swift review and correction of CIDR IP configurations in your security groups is strongly recommended to uphold network security.	The Instances that are connected to this security group, can be accidentally exposed to the Internet and compromised.
Public Exposure	Security Group Allows Access From Any IP (0.0.0.0/0)	A security group with an inbound network rule that allows incoming connection from any IP address (0.0.0.0/0) to any port.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group Permits Connections From Any IP (0.0.0.0/0)	This risk points to an AWS Security Group configured to allow incoming connections from any IP address, denoted by the range 0.0.0.0/0. This unrestricted access can lead to potential unauthorized access and data breaches. It's recommended to validate the need for such open access, and if it is not required, promptly implement stricter access control based on specific IP addresses or ranges.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Exposed RDP Port	This risk identifies a Security Group that has the RDP port (3389) open to the public, posing a significant security risk. Unauthorized access to the RDP port can potentially allow cyber attackers to control your AWS resources. It's crucial to review and restrict access to the RDP port, limiting it to specific, necessary IP ranges or secure VPN connections, to strengthen your system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Exposed Telnet Port	This risk underscores a Security Group that has the Telnet port (23) open to the public. An open Telnet port can be a significant security vulnerability as it can allow unauthorized access to your AWS resources. This exposure could potentially lead to unauthorized data access, data breaches, or unwanted modifications. It's highly advised to review and tighten access to the Telnet port, limiting it to necessary IP ranges or more secure protocols. Swift action to restrict this access will greatly enhance your AWS security posture and reduce potential cyber attack vectors.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Open Cassandra Port	This risk signifies a Security Group that has the Cassandra port (9142) open to the public. This can allow unauthorized access to your Cassandra databases, potentially leading to data breaches or malicious alterations. It's highly recommended to review and limit the port access to necessary IP ranges or secure connections, enhancing your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group With Open Kubernetes Kubelet Port (10250)	A security group with an inbound network rule that allows incoming connection from any IP address (0.0.0.0/0) to Kubernetes Kubelet port (10250).	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Open MySQL/MariaDB Port	This risk points to a Security Group that has the MySQL/MariaDB port (3306) open to the public. This can allow unauthorized access to your MySQL/MariaDB databases, potentially leading to data breaches or malicious alterations. It's highly recommended to review and limit the port access to necessary IP ranges or secure connections, greatly enhancing your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Open Redis Port	This risk signifies a Security Group with an open Redis port (6379), providing public access. This could potentially expose your Redis databases to unauthorized access and possible security breaches. A swift action to review and restrict access to the Redis port, limiting it to necessary IP ranges or secure VPN connections, is advised to fortify your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Kafka Port	This risk identifies a Security Group with an open Kafka port (9092), providing public access. This configuration could potentially expose your Kafka servers to unauthorized access and potential security threats. It's advised to promptly review and restrict access to the Kafka port, limiting it to necessary IP ranges or secure VPN connections, to improve your overall system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Kibana Port	This risk signifies a Security Group with an open Kibana port (5601), providing public access. This could potentially expose your Kibana instances to unauthorized access and potential security threats. It's advised to promptly review and restrict access to the Kibana port, limiting it to necessary IP ranges or secure VPN connections, to improve your overall system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Memcached Port	This risk highlights a Security Group configured with an open Memcached port (11211), allowing public access. This configuration can potentially expose your Memcached servers to unauthorized access and data breaches. It's recommended to promptly review and restrict access to the Memcached port, limiting it to necessary IP ranges or secure connections, thereby fortifying your server security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Redshift Port	This risk points to a security group configuration that leaves the Amazon Redshift port (5439) open to the public. An exposed Redshift port can increase the risk of unauthorized access and potential data breaches. It's recommended to verify the need for such a configuration and, if unnecessary, promptly restrict access to this port to enhance the security of your Redshift clusters.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible RPC Port	This risk highlights a Security Group configured with an open RPC port (135), making it publicly accessible. This configuration can potentially allow unauthorized access to your AWS resources. Open RPC ports are known to be vectors for certain types of cyber attacks, potentially leading to data breaches or unauthorized modifications. It's strongly recommended to review and limit access to the RPC port, confining it to necessary IP ranges or secure connections. Immediate action to secure this access will substantially enhance your AWS security and reduce potential cyber threats.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Exposed MSSQL Port	This risk signifies a Security Group configured with an open MSSQL port (1433), granting public access. This unrestricted access can potentially expose your SQL Server databases to unauthorized access and malicious activities. It's advised to immediately review and restrict the MSSQL port access to specific, necessary IP ranges or secure connections, enhancing your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Exposed Splunkd Port	This risk identifies a Security Group that has the Splunkd port (8089) open to the public. This configuration potentially leaves your Splunkd services vulnerable to unauthorized access and cyber threats. It's strongly recommended to review and limit access to the Splunkd port, confining it to specific, trusted IP ranges or secure VPN connections, to enhance your system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted FTP Ports	This risk highlights a Security Group that has FTP ports (20/21) open to the public. An open FTP port can allow unauthorized access to your AWS resources, potentially leading to data breaches, misuse, or unwarranted changes. It's strongly recommended to review and tighten access to these FTP ports, limiting them to specific, necessary IP ranges or secure connections. Prompt action to restrict this access will significantly enhance your AWS security and reduce exposure to potential cyber threats.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted PostgreSQL Port	This risk highlights a Security Group with an open PostgreSQL port (5432). This configuration can expose your PostgreSQL databases to unauthorized access and potential malicious activities. Promptly reviewing and restricting access to the PostgreSQL port, confining it to necessary IP ranges or secure connections, is strongly recommended to enhance your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted SMB Port Access	This risk category identifies a Security Group that has the SMB port (445) openly accessible to the public. An open SMB port can provide an entry point for unauthorized access to your AWS resources, potentially leading to data breaches or malicious modifications. This port is often targeted for exploits like the WannaCry ransomware attack. It's strongly recommended to review and restrict access to the SMB port, confining it to specific, necessary IP ranges or secure VPN connections. Taking immediate action to limit this access will significantly enhance your AWS security posture and reduce potential attack surfaces.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted SSH Port Access	This risk identifies a Security Group that has the SSH port (22) open to the public, potentially permitting unauthorized access to your AWS resources. It's crucial to review and restrict access to the SSH port, confining it to specific, necessary IP ranges or secure VPN connections, to bolster your system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unsecured DocDB Port	This risk indicates a Security Group that has the DocDB port (27017) open to the public. This configuration potentially leaves your DocumentDB databases exposed to unauthorized access and potential malicious actions. A swift review and restriction of access to the DocDB port, confining it to specific, trusted IP ranges or secure connections, is strongly recommended to uphold your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unsecured Elasticsearch Ports	This risk highlights a Security Group with Elasticsearch ports (9200/9300) open to the public. These open ports can potentially expose your Elasticsearch clusters to unauthorized access and possible cyber threats. Immediate review and restriction of access to these ports, limiting them to necessary IP ranges or secure connections, is strongly advised to bolster your cluster security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unsecured OracleDB Port	This risk highlights a Security Group that has the OracleDB port (1521) open to the public. This configuration potentially leaves your Oracle databases exposed to unauthorized access and cyber attacks. A swift review and restriction of access to the OracleDB port, confining it to specific, trusted IP ranges or secure connections, is strongly recommended to uphold your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.

Amazon ElastiCache

Category	Risk Name	Description	Attack Scenario
Data Security	Elasticache User (Not Default) Access String Allows Access to All Keys and Commands	Allowing access to all keys and commands through the Elasticache User Access String provides overly broad and unrestricted access, which can lead to unauthorized data manipulation or misuse.	An attacker gains access to the Elasticache User Access String with permissions for all keys and commands. They could potentially launch a series of malicious operations, such as deleting critical data, injecting harmful commands, or exfiltrating sensitive information, posing a significant security threat to the system's integrity and confidentiality.
Data Security	Elasticache User without Authentication	When a user in Elasticache lacks authentication, a significant security vulnerability arises as there are no authentication mechanisms in place to verify the legitimacy of user requests, potentially exposing the system to unauthorized access and misuse.	An attacker could impersonate a user to gain unrestricted access to the cluster. This could lead to unauthorized data retrieval, manipulation, or even the injection of malicious data into the cache, compromising data integrity.
Identity & Access Management	Elasticache Default User is in UserGroups	In Elasticache, a default user is automatically configured with the user ID and name "default," and it is added to all user groups, while remaining immutable and unable to be deleted or modified. This user is granted an access string that allows it to execute all commands and access all keys, creating a potential security vulnerability by providing overly broad and unmodifiable access privileges.	An attacker gains access to the cluster using the default user, taking advantage of the absence of authentication requirements and the user's full access privileges, which allows them to perform unauthorized operations.
Identity & Access Management	Non Default Elasticache User Not Associated With Any Group	A user not associated with any group.
Identity & Access Management	Non Default Elasticache User Not Associated With Any Group that Has High Permissions	A user in Elasticache who possesses a full access string or is authenticated independently (without relying on IAM) lacks the security benefits of centralized access control and proper management, thereby increasing the risk of unauthorized access, misconfigurations, and making it challenging to efficiently audit and administer user permissions.	An attacker discovers an unsupervised Elasticache user, initially created without specific permissions. If this user is later added to a group with elevated privileges without proper review, the attacker seizes the moment, gaining unauthorized access to critical resources.
Insecure Configurations	Elasticache Encryption by Rest is disabled	Disabling encryption by rest in AWS ElastiCache can potentially lead to security vulnerabilities, as sensitive data may become exposed to potential unauthorized access, data breaches, or compromises due to the absence of encryption safeguards for stored data.	An attacker gains unauthorized access to the Elasticache cluster. Since Encryption at Rest is disabled, they can easily access and exfiltrate sensitive data, such as cached passwords or confidential information, potentially leading to data breaches or unauthorized data exposure.
Insecure Configurations	Elasticache Encryption by Transit is disabled	Disabling Encryption in Transit in Elasticache creates a security problem by allowing data transmitted between clients and the cluster to be susceptible to interception, potentially compromising data confidentiality and integrity.	An attacker with access to the network infrastructure or a compromised intermediary device can exploit Elasticache Encryption in Transit being disabled to intercept and eavesdrop on unencrypted data packets transmitted between clients and the cache, potentially compromising data confidentiality and integrity.
Insecure Configurations	Elasticache User with Password Authentication Only	When a user in Elasticache relies solely on authentication by password, the security concern arises if the chosen password is weak or easily guessable, as it can create a vulnerability where malicious actors may successfully guess or crack the password, leading to unauthorized system access and potential compromises to data integrity and confidentiality.	An attacker can employ brute-force or dictionary attacks to repeatedly guess the password.

Amazon ELB

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf.
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0.
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.

AWS IAM

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	IAM User Access Key Unrotated for Over 90 Days	This risk identifies an Amazon IAM (Identity and Access Management) user whose access key hasn't been rotated for over 90 days. Keeping access keys unrotated for prolonged periods can increase the risk of unauthorized access if the keys are compromised. It's recommended to adopt a practice of regular key rotation, ideally, every 90 days, to ensure secure access management.	An attacker with access to the access key can achieve the user's privileges and perform unauthorized actions in the account.
Identity & Access Management	IAM User Holding Unused, Outdated Access Keys	This risk signifies an IAM user that has access keys not used for over 90 days. Outdated, unused keys can pose a significant security risk if they are compromised. It's strongly advised to review and rotate old access keys, promptly deactivating any that are unused to enhance account security.	An attacker with access to the access key can achieve the user's privileges and perform unauthorized actions in the account.
Identity & Access Management	Inactive IAM User Access Key	This risk indicates an inactive access key associated with an Amazon IAM (Identity and Access Management) user. Despite being inactive, these keys can pose a potential security risk if they were to be reactivated without appropriate controls. It's recommended to routinely review and manage inactive keys, eliminating or rotating those that aren't needed, to maintain a robust access management system.
Identity & Access Management	IAM User With Old Password For Over 90 Days	User unchanged his password in the last 90 days.	Attacker can use this user for getting access to compromised environment.
Identity & Access Management	IAM User Without MFA	This risk identifies an Amazon IAM (Identity and Access Management) user who doesn't have Multi-Factor Authentication (MFA) enabled. MFA provides an extra layer of security by requiring more than just a password for user authentication. Without MFA, the user's account is at a higher risk of unauthorized access. Enabling MFA for all IAM users is strongly recommended to bolster account security.	An attacker can bypass authentication with a password only.
Identity & Access Management	Inactive IAM User In IAM Credential Report	Inactive user is user with unused access key or user that didn't connect to aws console in the last 90 days.	Attacker can use inactive user credentials that leading to environment compromised
Identity & Access Management	IAM Role Configured with Predictable External ID	This risk points to an IAM role that has a predictable external ID. Such easily guessed IDs can potentially allow unauthorized entities to assume the role, posing a risk of unauthorized access and potential security breaches. A review and update of all IAM role external IDs, ensuring they are complex and unpredictable, is strongly recommended to maintain secure role access.	"An attacker can trick a third party that can assume a role in your account, and gain unauthorized access to your resources. External ID is a unique identifier that third parties use to assume a role in your account, and its purpose is to prevent the confused deputy problem. When the external id can be easily guessed, the confused deputy remains a problem. We look for external id values that have less than three different types of characters, contain sequences such as 123, abc, qwe, and more, or that are included in the role ARN (account id, role name)."
Identity & Access Management	IAM Role Configured with Unrestricted Assume Role Permissions	This risk identifies an IAM Role that has been configured to allow 'Assume Role' permissions to any AWS user. This broad configuration increases the potential of unauthorized access to the resources associated with this IAM role. It can lead to misuse of permissions, data breaches, or even alteration of your AWS services. It's highly recommended to review and restrict the 'Assume Role' permissions to specific users or roles, thereby enhancing your AWS security posture by reducing unnecessary exposure.	An attacker with access to any AWS account can assume the role and use its permissions.

AWS Key Management Service

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	KMS Key Allows Anonymous Access	A key policy that allows certain actions to all users.	If there are no other access mechanisms with deny statements that override this permissive key policy, an attacker will be able to perform the specified actions on your key.
Neglected Resource	KMS Customer Managed Key Without Rotation	A customer-managed key with disabled key rotation.	Key rotation reduces the risk of a compromised key being used by an attacker to access your encrypted resources.
Neglected Resource	Unusable Customer Managed Key	A customer-managed KMS key that can't be used. The key is either disabled or pending deletion.	It is not a best practice to have usable keys as it can harm key management processes and increase your monthly AWS bill.

AWS Lambda

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	"When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf."
Insecure Configurations	Lambda Function Security Group
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	"This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0."
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.
Public Exposure	Public Lambda Function Without Authentication	"Lambda Function that is configured with a function URL and without authentication. OWASP A6:2017 <a href=""https://owasp.org/www-pdf-archive/OWASP-Top-10-Serverless-Interpretation-en.pdf""Security> Misconfiguration."	A function URL is a dedicated HTTPS endpoint that allows access and invocation of the function from the public Internet. The configuration of the detected function also supports unauthenticated access, which allows anyone from the Internet to trigger it.
Unsupported Software	Lambda Function Operating on Deprecated Runtime	"This risk identifies a Lambda function operating on a runtime that is deprecated or has reached end of support. Operating on such a runtime can expose the function to unpatched vulnerabilities and reduce overall performance. An immediate update to a supported runtime is recommended to ensure the security and efficiency of your Lambda function. OWASP A6:2017 <a href=""https://owasp.org/www-pdf-archive/OWASP-Top-10-Serverless-Interpretation-en.pdf""Security> Misconfiguration."	An attacker can exploit known unpatched vulnerabilities in the Lambda function runtime

Amazon Neptune

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Neptune Cluster has Short Retention Period	Neptune database has less than 7 days backup retention period.	A backup retention period ensures that you have a reliable copy of your data in case of accidental deletion, corruption, or other data loss events.
Insecure Configurations	Neptune DB Storage Encrypted Enabled
Insecure Configurations	Neptune IAM Database Authentication Disabled	IAM Database Authentication in Amazon Neptune provides an additional layer of security for accessing your Neptune database. Instead of using a traditional username and password for database authentication, IAM Database Authentication allows you to use AWS Identity and Access Management (IAM) credentials to authenticate to your Neptune database.	Attackers might attempt to break traditional authentication methods by brute force or password guessing attacks.
Insecure Configurations	Neptune without Deletion Protection	Deletion protection is disabled.	Disabling deletion protection in Neptune DB can introduce several security risks. Deletion protection is a feature that prevents accidental or unauthorized data deletions, and disabling it can make your database more vulnerable to various threats.
Insecure Configurations	Neptune Without Storage Encryption	An attacker with access to the Neptune database can access sensitive data that stored in it.	This risk indicates an Amazon Neptune database that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.

Amazon RDS

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	"When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf."
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	"This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0."
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.
Data Security	RDS Cluster Without Configured Backup Retention	This risk signifies an Amazon RDS cluster not configured for backup retention. A lack of backup retention can lead to data loss in case of system failures or errors. It's highly recommended to configure a suitable backup retention policy to protect data and ensure the possibility of recovery in the event of unexpected issues.	The backup retention period determines the period for which you can perform a point-in-time recovery.
Data Security	RDS Database Instance Publicly Accessible	This risk identifies an Amazon RDS database instance configured to allow public access, making it potentially reachable by any AWS user or internet user. Publicly accessible database instances pose a heightened risk of unauthorized data access and potential data breaches. It's recommended to validate whether such public access is necessary and, if not, promptly restrict the access to enhance the security of your data.	An attacker can access the DB leading to data exposure.
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	"When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf."
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	"This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0."
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.
Data Security	RDS Cluster Database Snapshot Publicly Shared	This risk signifies a publicly shared Amazon RDS cluster database snapshot, making it accessible to any AWS user. Publicly sharing snapshots elevates the risk of unauthorized access, data misuse, or breaches. The necessity of this public sharing should be verified; if not required, immediate action to restrict the sharing is advised to minimize potential security risks.	DB cluster snapshot is public and available for any Amazon Web Services account to copy or restore.
Data Security	RDS Cluster Database Snapshot Without Encryption	This risk highlights an Amazon RDS cluster database snapshot that is without encryption. Encryption serves as a vital security layer, safeguarding sensitive data from unauthorized access and potential breaches. An unencrypted snapshot increases the likelihood of data misuse if it's unintentionally accessed or shared. Prompt action to apply encryption is recommended to ensure the security of the snapshot's data.	An attacker can access the data stored in the RDS cluster database snapshot without decrypting it.
Data Security	RDS Database Cluster Snapshot Externally Shared	This risk signifies an Amazon RDS database cluster snapshot shared with an external AWS account, potentially risking exposure of sensitive data. Uncontrolled or untrusted accounts might misuse or further expose this data, leading to potential breaches and compliance issues. Immediate investigation and appropriate action, such as revoking sharing if it violates security policies, are recommended to mitigate potential risks.	An attacker with access to the external account can copy the database cluster snapshot and create a RDS database cluster.
Data Security	RDS Database Snapshot Externally Shared	This risk signifies an Amazon RDS database snapshot shared with an external AWS account, potentially risking exposure of sensitive data. Uncontrolled or untrusted accounts might misuse or further expose this data, leading to potential breaches and compliance issues. Immediate investigation and appropriate action, such as revoking sharing if it violates security policies, are recommended to mitigate potential risks.	An attacker with access to the external account can copy the database snapshot and create a RDS database.
Data Security	RDS Database Snapshot Publicly Shared	This risk signifies a publicly shared Amazon RDS database snapshot, making it accessible to any AWS user. Publicly sharing snapshots elevates the risk of unauthorized access, data misuse, or breaches. The necessity of this public sharing should be verified; if not required, immediate action to restrict the sharing is advised to minimize potential security risks.	DB snapshot is public and available for any Amazon Web Services account to copy or restore it.
Data Security	RDS Database Snapshot Without Encryption	This risk highlights an Amazon RDS database snapshot that is without encryption. Encryption serves as a vital security layer, safeguarding sensitive data from unauthorized access and potential breaches. An unencrypted snapshot increases the likelihood of data misuse if it's unintentionally accessed or shared. Prompt action to apply encryption is recommended to ensure the security of the snapshot's data.	An attacker can access the data stored in an RDS snapshot without decrypting it.

Amazon Redshift

Category	Risk Name	Description	Attack Scenario
Data Security	Redshift Cluster Publicly Accessible	This risk points to an Amazon Redshift cluster configured to be publicly accessible, potentially making it reachable by any internet user. Publicly accessible Redshift clusters can significantly raise the risk of unauthorized data access and potential data breaches. It's recommended to validate the need for such public access and, if unnecessary, promptly restrict access to strengthen your data security.	An attacker can access Redshift cluster through the cluster endpoint.
Data Security	Redshift Cluster Without Encryption	This risk identifies an Amazon Redshift cluster that has not been configured for encryption, a crucial security measure to protect sensitive data from unauthorized access. Unencrypted Redshift clusters present an increased risk of data exposure or misuse. Implementing encryption to secure your data and adhere to best practices and compliance regulations is strongly recommended.	An attacker can access the data stored in your Redshift cluster.

Amazon Route 53

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Public Route53 Hosted Zone Holding Private DNS Record	This risk points to a Route53 hosted zone that is public yet contains private DNS records. This configuration can lead to unintended exposure of internal resource information, heightening the risk of unauthorized access and potential breaches. A prompt review of the hosted zone's configuration to ensure appropriate privacy for DNS records is strongly recommended.	All DNS in a public hosted zone can be queried from any external internet IP address. An attacker can resolve these records and gain information about your environment.
Insecure Configurations	Route53 Without Auto Renew Domain	A Route 53 domain with the auto renew feature not enabled.	With the auto renew feature enabled, your domains won't get expired. Expired domains leave your application exposed to multiple attacks, so it is best practice to enable the feature.
Insecure Configurations	Route53 Without Domain Transfer Lock	A Route 53 domain with Transfer Lock set to false.	An attacker may be able to transfer your domain to another domain name registrar, and hijack your domain.

Neglected Resource	Route53 Domain Expires In 30 Days	A Route 53 domain is going to be expired in 30 days.	Expired domains leave your application exposed to multiple attacks. Extend the expiration date as soon as possible.
Neglected Resource	Route53 Domain Expires In 7 Days	A Route 53 domain is going to expire in 7 days.	Expired domains leave your application exposed to multiple attacks. Extend the expiration date as soon as possible.
Neglected Resource	Route53 With Expired Domain	An expired domain name is registered in Route 53.	An attacker can hijack the expired domain and use it for malicious purposes. In addition, an expired domain can cause failures or downtime in your application.

Amazon S3

Category	Risk Name	Description	Attack Scenario
Data Security	Cross-Account S3 Bucket Access	This risk indicates that an Amazon S3 bucket is configured to permit access from users in different AWS accounts. If not strictly controlled, cross-account access can elevate the risk of unauthorized data access or leakage. It's advisable to scrutinize the necessity of this access configuration and promptly modify the bucket's access policies to enhance your data security if not required.	An attacker from any AWS account can define this S3 bucket as their target bucket for the service logs or configuration.
Data Security	S3 Bucket Contains Potentially Public Objects	This risk identifies an Amazon S3 bucket that contains objects that may be publicly accessible, thereby potentially enabling any internet user to access them. Potentially shared objects in an S3 bucket can heighten the risk of unauthorized data access and potential data breaches. It's recommended to review these objects and their access controls, and if public access is not necessary, promptly update their permissions to secure your data.	An attacker can maybe access some objects in the bucket leading to data exposure.
Data Security	S3 Bucket Encrypted with AWS S3 Managed Key	S3 bucket encrypted with AWS S3 managed key.	Using AWS S3 managed key to encrypt an S3 bucket in AWS is not recommended due to limited control over key management. Managing your own KMS keys allows for better security practices, ensures isolation of resources, and facilitates compliance with industry standards. Creating and using customer-managed keys provides a more robust and customizable approach to data encryption in AWS S3.
Data Security	S3 Bucket Publicly Accessible	This risk points to an Amazon S3 bucket configured as publicly accessible, potentially making it reachable by any internet user. Publicly accessible S3 buckets significantly reduce the risk of unauthorized data access and potential breaches. It's recommended to validate the need for such public access, and if it's not necessary, promptly restrict access to improve your data security.	An attacker can access the bucket and objects leading to data exposure.
Insecure Configurations	EC2 Instance Operating with Unsecured Metadata Service	This risk points to an EC2 instance that has metadata services enabled without the necessary security tokens. Without these tokens, the metadata services, which can hold sensitive information about the EC2 instance, are exposed to potential unauthorized access. This vulnerability can lead to security breaches and data leaks. It is strongly recommended to secure the metadata services by implementing required security tokens, ensuring proper authorization, and thereby safeguarding the integrity of the instance's metadata.	When the instance is public and has a connection to the internet, the attacker can take advantage of these default configurations and get full access to the instance and its permissions. This is a default configuration that most of the developers are not aware of. The default configuration can leave your environment at increased risk in the event of a credential exposure/compromise. The metadata information is available by making a request to the IP address of 169.254.169.254. The current AWS Metadata service does not require any HTTP headers to be present and allows any process to make HTTP requests, and it allows an attacker to trick the instance with SSRF (server-side request forgery) vulnerability and making an HTTP/HTTPS requests on his behalf.
Insecure Configurations	Load Balancer Operating with Outdated SSLv3 Protocol	This risk category identifies a Load Balancer that is configured to use the outdated SSLv3 protocol. The SSLv3 protocol has known vulnerabilities and its use poses a significant security risk, including susceptibility to the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. It is strongly advised to update the Load Balancer's configuration to use a more secure, modern protocol such as TLS 1.2 or TLS 1.3. By doing so, you can reduce the risk of data breaches and ensure secure, encrypted communication.	This version has a flaw that could allow an attacker to decrypt information, such as authentication cookies. This vulnerability is known as POODLE attack - man-in-the-middle exploits which take advantage of Internet and security software clients' fallback to SSL 3.0.
Insecure Configurations	RDS Database Instance Without Encryption	An attacker with access to the RDS DB can access sensitive data stored in the DB.	This risk indicates an Amazon RDS database instance that lacks encryption, a critical security measure to safeguard sensitive data from unauthorized access. Unencrypted database instances raise the risk of data exposure or misuse, mainly if accessed by unauthorized entities. Implementing encryption to secure your data and comply with best practices and regulations is strongly recommended.

AWS Secrets Manager

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Secret Manager Secret Not Rotated Over 30 Days	Secret not rotated for over 30 days.	An attacker with access to the secret can get its content and elevate his privileges.

Amazon VPC

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Default Security Group
Insecure Configurations	Security Group with Inappropriately Configured CIDR IP	This risk highlights a Security Group with a misconfigured CIDR IP, which may expose your resources to unintended networks, leading to potential unauthorized access. A swift review and correction of CIDR IP configurations in your security groups is strongly recommended to uphold network security.	The Instances that are connected to this security group, can be accidentally exposed to the Internet and compromised.
Public Exposure	Security Group Allows Access From Any IP (0.0.0.0/0)	A security group with an inbound network rule that allows incoming connection from any IP address (0.0.0.0/0) to any port.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group Permits Connections From Any IP (0.0.0.0/0)	This risk points to an AWS Security Group configured to allow incoming connections from any IP address, denoted by the range 0.0.0.0/0. This unrestricted access can lead to potential unauthorized access and data breaches. It's recommended to validate the need for such open access, and if it is not required, promptly implement stricter access control based on specific IP addresses or ranges.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Exposed RDP Port	This risk identifies a Security Group that has the RDP port (3389) open to the public, posing a significant security risk. Unauthorized access to the RDP port can potentially allow cyber attackers to control your AWS resources. It's crucial to review and restrict access to the RDP port, limiting it to specific, necessary IP ranges or secure VPN connections, to strengthen your system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Exposed Telnet Port	This risk underscores a Security Group that has the Telnet port (23) open to the public. An open Telnet port can be a significant security vulnerability as it can allow unauthorized access to your AWS resources. This exposure could potentially lead to unauthorized data access, data breaches, or unwanted modifications. It's highly advised to review and tighten access to the Telnet port, limiting it to necessary IP ranges or more secure protocols. Swift action to restrict this access will greatly enhance your AWS security posture and reduce potential cyber attack vectors.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Open Cassandra Port	This risk signifies a Security Group that has the Cassandra port (9142) open to the public. This can allow unauthorized access to your Cassandra databases, potentially leading to data breaches or malicious alterations. It's highly recommended to review and limit the port access to necessary IP ranges or secure connections, enhancing your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group With Open Kubernetes Kubelet Port (10250)	A security group with an inbound network rule that allows incoming connection from any IP address (0.0.0.0/0) to Kubernetes Kubelet port (10250).	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Open MySQL/MariaDB Port	This risk points to a Security Group that has the MySQL/MariaDB port (3306) open to the public. This can allow unauthorized access to your MySQL/MariaDB databases, potentially leading to data breaches or malicious alterations. It's highly recommended to review and limit the port access to necessary IP ranges or secure connections, greatly enhancing your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Open Redis Port	This risk signifies a Security Group with an open Redis port (6379), providing public access. This could potentially expose your Redis databases to unauthorized access and possible security breaches. A swift action to review and restrict access to the Redis port, limiting it to necessary IP ranges or secure VPN connections, is advised to fortify your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Kafka Port	This risk identifies a Security Group with an open Kafka port (9092), providing public access. This configuration could potentially expose your Kafka servers to unauthorized access and potential security threats. It's advised to promptly review and restrict access to the Kafka port, limiting it to necessary IP ranges or secure VPN connections, to improve your overall system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Kibana Port	This risk signifies a Security Group with an open Kibana port (5601), providing public access. This could potentially expose your Kibana instances to unauthorized access and potential security threats. It's advised to promptly review and restrict access to the Kibana port, limiting it to necessary IP ranges or secure VPN connections, to improve your overall system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Memcached Port	This risk highlights a Security Group configured with an open Memcached port (11211), allowing public access. This configuration can potentially expose your Memcached servers to unauthorized access and data breaches. It's recommended to promptly review and restrict access to the Memcached port, limiting it to necessary IP ranges or secure connections, thereby fortifying your server security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible Redshift Port	This risk points to a security group configuration that leaves the Amazon Redshift port (5439) open to the public. An exposed Redshift port can increase the risk of unauthorized access and potential data breaches. It's recommended to verify the need for such a configuration and, if unnecessary, promptly restrict access to this port to enhance the security of your Redshift clusters.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Accessible RPC Port	This risk highlights a Security Group configured with an open RPC port (135), making it publicly accessible. This configuration can potentially allow unauthorized access to your AWS resources. Open RPC ports are known to be vectors for certain types of cyber attacks, potentially leading to data breaches or unauthorized modifications. It's strongly recommended to review and limit access to the RPC port, confining it to necessary IP ranges or secure connections. Immediate action to secure this access will substantially enhance your AWS security and reduce potential cyber threats.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Exposed MSSQL Port	This risk signifies a Security Group configured with an open MSSQL port (1433), granting public access. This unrestricted access can potentially expose your SQL Server databases to unauthorized access and malicious activities. It's advised to immediately review and restrict the MSSQL port access to specific, necessary IP ranges or secure connections, enhancing your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Publicly Exposed Splunkd Port	This risk identifies a Security Group that has the Splunkd port (8089) open to the public. This configuration potentially leaves your Splunkd services vulnerable to unauthorized access and cyber threats. It's strongly recommended to review and limit access to the Splunkd port, confining it to specific, trusted IP ranges or secure VPN connections, to enhance your system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted FTP Ports	This risk highlights a Security Group that has FTP ports (20/21) open to the public. An open FTP port can allow unauthorized access to your AWS resources, potentially leading to data breaches, misuse, or unwarranted changes. It's strongly recommended to review and tighten access to these FTP ports, limiting them to specific, necessary IP ranges or secure connections. Prompt action to restrict this access will significantly enhance your AWS security and reduce exposure to potential cyber threats.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted PostgreSQL Port	This risk highlights a Security Group with an open PostgreSQL port (5432). This configuration can expose your PostgreSQL databases to unauthorized access and potential malicious activities. Promptly reviewing and restricting access to the PostgreSQL port, confining it to necessary IP ranges or secure connections, is strongly recommended to enhance your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted SMB Port Access	This risk category identifies a Security Group that has the SMB port (445) openly accessible to the public. An open SMB port can provide an entry point for unauthorized access to your AWS resources, potentially leading to data breaches or malicious modifications. This port is often targeted for exploits like the WannaCry ransomware attack. It's strongly recommended to review and restrict access to the SMB port, confining it to specific, necessary IP ranges or secure VPN connections. Taking immediate action to limit this access will significantly enhance your AWS security posture and reduce potential attack surfaces.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unrestricted SSH Port Access	This risk identifies a Security Group that has the SSH port (22) open to the public, potentially permitting unauthorized access to your AWS resources. It's crucial to review and restrict access to the SSH port, confining it to specific, necessary IP ranges or secure VPN connections, to bolster your system security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unsecured DocDB Port	This risk indicates a Security Group that has the DocDB port (27017) open to the public. This configuration potentially leaves your DocumentDB databases exposed to unauthorized access and potential malicious actions. A swift review and restriction of access to the DocDB port, confining it to specific, trusted IP ranges or secure connections, is strongly recommended to uphold your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unsecured Elasticsearch Ports	This risk highlights a Security Group with Elasticsearch ports (9200/9300) open to the public. These open ports can potentially expose your Elasticsearch clusters to unauthorized access and possible cyber threats. Immediate review and restriction of access to these ports, limiting them to necessary IP ranges or secure connections, is strongly advised to bolster your cluster security.	An attacker might use this misconfiguration to access assets within the AWS environment.
Public Exposure	Security Group with Unsecured OracleDB Port	This risk highlights a Security Group that has the OracleDB port (1521) open to the public. This configuration potentially leaves your Oracle databases exposed to unauthorized access and cyber attacks. A swift review and restriction of access to the OracleDB port, confining it to specific, trusted IP ranges or secure connections, is strongly recommended to uphold your database security.	An attacker might use this misconfiguration to access assets within the AWS environment.

SNS (Simple Notification Service)

Category	Risk Name	Description	Attack Scenario
Data Security	SNS Topic Encryption is Not Enabled	The absence of encryption for SNS topics exposes transmitted messages to risks of unauthorized access, interception, and tampering, compromising the confidentiality, integrity, and privacy of sensitive information within the messages.	In an environment where an SNS topic lacks encryption, an attacker can gain unauthorized access. Through this access, an attacker can intercept messages transmitted through the unencrypted SNS topic, enabling them to extract sensitive information.
Data Security	SNS Topic is Encrypted With a Default Key	Using the default key for encrypting SNS topics presents limitations in effective key management. Default key does not allow the ability to create, rotate, disable or enable the encryption key used to protect the data.	The default key used for encryption in AWS lacks the necessary mechanisms to provide secure end-to-end encryption and prevent a Man-in-the-Middle attack on SNS topics. This makes it vulnerable to interception and manipulation by an attacker.
Insecure Configurations	SNS Topic Data-in-Transit is Not Enforced	An SNS topic without HTTPS enforcment.	Without HTTPS, a network-based attacker can eavesdrop on network traffic or manipulate it using an attack such as man-in-the-middle.
Insecure Configurations	SNS Topic Policy Allows 'SNS:Publish' for All Principals Without Conditions	The security finding of an SNS topic policy allowing unrestricted 'SNS:Publish' access increses the risk of unauthorized message dissemination, abuse, compromised data integrity, and non-compliance with security regulations.	An attacker identifies the SNS topic with the open publishing access and leverages this vulnerability to send unauthorized messages to the topic. With the ability to publish messages without restrictions, the attacker can disseminate malicious content, such as phishing links, malware payloads, or false information to the subscribers of the topic.
Insecure Configurations	SNS Topics Administrative Actions Are Publicly Executable	Preventing public execution of administrative actions on SNS topics is essential to maintain messaging system security, safeguard sensitive data, prevent service disruptions, and ensure compliance by restricting unauthorized users from performing administrative operations.	An attacker identifies a publicly accessible SNS topic and discovers that administrative actions can be executed without authentication. With this control, the attacker can modify topic settings, change access permissions, or delete the topic altogether.
Insecure Configurations	SNS Topics Are Publicly Accessible	Ensuring that SNS is not publicly accessible is important to protect against unauthorized access, data breaches, and other security threats.	An attack targeting the Simple Notification Service (SNS) public access could involve unauthorized actors exploiting the open access configuration of an SNS topic. By identifying a publicly accessible SNS topic, the attackers can abuse it to send messages or notifications to a large number of recipients, potentially causing disruptions, spamming users, or spreading malicious content.

SQS (Simple Queue Service)

Category	Risk Name	Description	Attack Scenario
Data Security	SQS Queue is Not Encrypted With a Customer-Managed Key	SQS (Simple Queue Service) not being encrypted with a customer-managed key increases the risk of unauthorized access and potential exposure of sensitive data.	When SQS is not encrypted with a customer-managed key, the messages stored in SQS are still encrypted using AWS-managed keys. Without customer-managed key encryption. KMS key allows a more granular control over the SQS data encryption/decryption process.
Data Security	SQS Server-Side Encryption is Not Enabled	Disabling AWS SQS Server-Side Encryption (SSE) exposes data to vulnerabilities, non-compliance with data protection regulations, compromises data integrity, and undermines trust in the service.	When Server-Side Encryption (SSE) is not enforced in SQS, an attacker with unauthorized access can intercept and read unencrypted messages stored in the queue, leading to data exposure.
Insecure Configurations	SQS Data-in-Transit Encryption is Not Enforced	Not enforcing data-in-transit encryption in SQS (Simple Queue Service) increases the risk of data interception and unauthorized access during the transmission of messages.	The transmitted messages are vulnerable to interception by malicious actors. Attackers can eavesdrop on network traffic or manipulate it, using an attack such as man-in-the-middle.
Insecure Configurations	SQS Policy Allows All Actions From All Principals Without a Condition	Allowing all actions from all principals without conditions in AWS SQS eliminates access control, increases the risk of unauthorized operations, data breaches, compliance violations, and operational disruptions.	In a scenario where there is a lack of access control in AWS SQS, allowing all actions from all principals without conditions, any AWS identity or entity has unrestricted access to perform any action on the SQS queues. This absence of granular access controls and restrictions allows an attacker to exploit this lack of control by gaining unauthorized access to sensitive data within the queues.
Insecure Configurations	SQS Policy Allows Public Access	SQS (Simple Queue Service) policy that allows public access increases the risk of unauthorized users gaining access to the queue and potentially manipulating or retrieving sensitive messages.	When an SQS (Simple Queue Service) policy is misconfigured to allow public access, unauthorized individuals can exploit this vulnerability. Attackers can manipulate and retrieve sensitive messages from the queue without any authentication or authorization checks.

Microsoft Azure - click to collapse

Microsoft Azure

Click on a service name below to view a table of the risks Panoptica detects in Azure, along with brief descriptions and attack scenarios.

Azure App Service

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Azure Function Cross-origin Resource Sharing (CORS) Feature not Implemented	Cross-Origin Resource Sharing (CORS) is a security feature that allows or restricts web applications running at one origin (domain) to make requests for resources from a different origin, subject to certain constraints, to prevent unauthorized access to data. This finding signifies an Azure Function without Cross-Origin Resource Sharing enforcement.	An attacker could exploit permissive CORS policies set on a web application to make unauthorized cross-origin requests, potentially gaining access to sensitive data or performing actions on behalf of a legitimate user without their consent. For example, an attacker might trick a victim into visiting a malicious website that sends requests to a trusted web service using the victim's credentials, allowing the attacker to steal data or perform actions on the victim's behalf.
Insecure Configurations	Azure Function Enables Unencrypted Traffic	An Azure Function without HTTPS enforcment.	Without HTTPS, a network-based attacker can eavesdrop on network traffic or manipulate it using an attack such as man-in-the-middle.
Insecure Configurations	Azure Function Support Insecure Transportation Security Protocol	An Azure Function that uses insecure TLS (Transport Layer Security) protocols.	It is recommended to use the latest version of TLS if possible. Older versions (prior to TLS 1.2) may be deprecated or may contain known vulnerabilities that an attacker can use.
Insecure Configurations	FTP Service Enabled for Azure Function	An Azure Function S/FTP endpoint enabled.	The Azure FTP deployment endpoints are publicly accessible. An attacker might attempt to brute-force the service to gain access to the app/service code base.
Insecure Configurations	Remote Debugging is Enabled for Azure Function	An Azure Function that enables remote debugging.	If remote debugging in Azure Functions is enabled without proper security controls, an attacker could potentially gain unauthorized access to the running code, extract sensitive information, inject malicious code, or disrupt the application, posing a significant security risk.
Unsupported Software	Azure Function Deprecated Runtime	Azure function with a deprecated runtime.	An attacker can exploit known unpatched vulnerabilities in the azure function runtime.

Azure Container Instance (ACI)

Azure Container Instance (ACE)

Category	Risk Name	Description	Attack Scenario
Public Exposure	Public Storage Account Container	Container with public access allowed.	In some cases, an attacker will be able to access data stored in the container.

Azure Cosmos DB

Category	Risk Name	Description	Attack Scenario
Data Security	Cosmos DB Connection From Public Azure Data Centers Enabled	This option configures the firewall to allow all requests from Azure, including requests from the subscriptions of other customers deployed in Azure.	In a scenario where a Cosmos DB account allows connections from IP address "0.0.0.0" (representing all public data centers), an attacker with an unauthorized account could exploit this configuration by gaining access from any location. This attacker could potentially infiltrate the Cosmos DB account, extract sensitive data, launch malicious queries, or even manipulate the database's content, all while leveraging the unrestricted public IP allowance.
Insecure Configurations	Cosmos DB Account "Disabled Key Based Metadata Write Access" is Disabled	A CosmosDB Database with "Disabled Key Based Metadata Write Access" option disabled.	In a scenario where "disabled key based metadata write access" is disabled, an attacker could potentially exploit this vulnerability by gaining unauthorized access to modify or tamper with metadata using compromised keys. This could lead to unauthorized privilege escalation, data manipulation, or confusion in data organization, impacting the integrity and security of the Cosmos DB resources.
Insecure Configurations	Cosmos DB Account is Not Using Virtual Network	Enabling Virtual Network integration for a Cosmos DB account is important as it adds an additional layer of security by restricting data access to specific networks, reducing exposure to potential threats.	In an attack scenario, if Virtual Network integration is not enabled for a Cosmos DB account, a malicious actor could exploit the lack of network restrictions by infiltrating the account through public endpoints, potentially compromising sensitive data or executing unauthorized operations on the database.
Insecure Configurations	Cosmos DB Account Local Auth is Enabled	Cosmos DB account local auth is enabled.	An attacker with access to these static keys, could potentially perform malicious actions such as data extraction, modification, or deletion. Since the keys are long-lived and not subject to regular rotation, the compromise could persist for an extended period, leading to significant data breaches and security breaches.
Insecure Configurations	Cosmos DB Account with Service Managed Encryption Key	Customer-Managed Keys (CMK) provide crucial advantage of retaining full control and ownership over their encryption keys, allowing them to enforce stricter access policies and meet regulatory compliance requirements.	An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access sensitive data stored in Cosmos DB.
Public Exposure	Cosmos DB Account Access is Allowed From All Networks	Azure Cosmos DB with public access enabled.	An attacker could exploit this misconfiguration by remotely connecting to the publicly open database and exfiltrating sensitive data.
Public Exposure	Cosmos DB Account is Not Using Private Endpoints	A CosmosDB database without private endpoints.	Not enabling Virtual Network integration for a Cosmos DB account can result in reduced security, potentially exposing data to unauthorized access.

Azure Database for MariaDB

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	MariaDB Server is Not Using Virtual Networks	Not using virtual networks in a MariaDB account poses a security risk as it exposes the database to potential unauthorized access and data exposure, lacking the additional layer of network isolation and security controls provided by virtual networks.	In a scenario where a virtual network is not configured, the communication occurs over the public internet unless there are other network-level controls in place. If the communication is not encrypted, it becomes susceptible to interception by attackers. These attackers can then execute a Man-in-the-Middle attack to intercept the traffic between the two entities.
Insecure Configurations	MariaDB Server TLS /SSL Disabled	MariaDB with disabled TLS/SSL option.	If TLS/SSL is disabled for a MariaDB account, an attacker on the same network could intercept the unencrypted database traffic, potentially capturing sensitive data such as passwords and queries.
Public Exposure	MariaDB Server Connection From Public Azure Services	Having a firewall rule allowing access from Azure Public Services in MariaDB could pose a security as it might permit access from a broader range of Azure services than necessary, potentially exposing the database to unintended and unnecessary connections within the Azure network.	An attacker exploits a misconfigured MariaDB firewall rule allowing access from any Azure Public Service, potentially gaining unauthorized entry through unintended services. Once inside, the attacker could perform malicious operations on the database, jeopardizing data integrity and confidentiality.
Public Exposure	MariaDB Server Has Full Public Network Access	Having Full public network access for all in a MariaDB account poses a security risk by potentially exposing the database to unauthorized access from any address.	An attacker, aware of the public network access on a MariaDB account for all, could exploit this vulnerability by launching attacks, attempting unauthorized logins, and potentially gaining control over the database, leading to unauthorized data access.
Public Exposure	MariaDB Server is Not Using Private Endpoints	MariaDB without a private endpoint configured.	An attacker could exploit network vulnerabilities to intercept unencrypted database communication, potentially capturing sensitive data or injecting malicious commands.

Azure Function

Category	Risk Name	Description	Attack Scenario
Public Exposure	Public Unauthenticated Function	A function with HTTP trigger and anonymous auth level. The HTTP trigger lets you invoke a function with an HTTP request, and the anonymous auth level lets you present a request without an API key.OWASP A2:2017 Broken Authentication.	An attacker can invoke the function, and in some cases can escape the function, gain the function app permissions and compromise your environment.

Azure OpenAI

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Azure OpenAI with Microsoft Managed Keys	Customer-Managed Keys (CMK) provide crucial advantage of retaining full control and ownership over your encryption keys, allowing you to enforce stricter access policies and meet regulatory compliance requirements.	An attacker who discovers a vulnerability in Azure's key management processes could potentially gain unauthorized access to encryption keys, enabling them to decrypt and access your Azure OpenAI data at rest such as the training data and fine-tuned models.
Public Exposure	Azure OpenAI Allow Access from All Networks	Azure OpenAI with public access enabled.	"Allowing unrestricted, public access to cloud services could open an application up to external attack. An Attacker can access the resource and access the models using api calls, by exploiting a different vulnerability of the service/models he can gain access to the service/models configurations and maybe even gain access to sensitive information."

Azure Resource Management (ARM)

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Role Definition With List Storage Account Keys Permissions	A role definition with permissions to list storage account keys.	An attacker with access to the role can accsses storage accounts with "allowSharedKeyAccess" set to true.
Identity & Access Management	Principal With Owner Role	Principal is assigned with the 'Owner' rolw that gives full permissions in the subscription.	An attacker with access to the principal can compromise the subscription.
Identity & Access Management	Principal With User Access Administrator Role	Principal assigned with the 'User Access Administrator' role that enables to manage user access to Azure resources.	An attacker with access to the principal can compromise the subscription.

Azure Virtual Network

Category	Risk Name	Description	Attack Scenario
Public Exposure	Network Security Group With Open RDP Port (3389)	A network security group with RDP port (3389) open to any IP.	An attacker can try to exploit RDP vulnerabilities leaving your environment at risk.

Azure Storage Account

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Storage Account With 'non-secure' Connection	Storage account that allows requests from a non-secure connection.	An attacker can have access to your data through unencrypted communications with the storage account.
Insecure Configurations	Storage Account With Shared Key Access	Storage account with shared key access allowed. It is not a best practice to use shared key authorization for a storage account.	An attacker with access to a storage account key can access your storage account and compromise your data.
Public Exposure	Storage Account With Blob Public Access Allowed	A storage account with blob public access allowed. This setting allows public access to be configured for containers in the account but does not enable public access to your data.	In some cases, an attacker will be able to access your blobs and compromise your data.
Public Exposure	Storage Account With Unrestricted Network Access	Network access to the storage account is not restricted.	In some cases, an attacker would be able to access your storage account and the data stored in it.

Google Cloud Platform (GCP) - click to collapse

Google Cloud Platform (GCP)

Click on a service name below to view a table of the risks Panoptica detects in GCP, along with brief descriptions and attack scenarios.

App Engine

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	App Engine Service With Default Service Account	By default App Engine service run with App Engine default service account, this service account has 'Editor' role in the project.	Attacker with access to App Engine service with default service account can deploy changes to the Cloud project can also run code with read/write access to all resources within that project.
Insecure Configurations	App Engine Service with Insecure Ingress Settings	This risk identifies a Google Cloud App Engine service configured with insecure ingress settings, potentially allowing unauthorized access. Insecure ingress settings can significantly heighten the risk of unauthorized access and potential data breaches. It's recommended to review these settings, and if the open access isn't necessary, promptly refine the ingress rules to enhance the security of your App Engine service.	An attacker can send direct requets to the app from the internet.
Public Exposure	App Engine App With Public Ingress Rule	App Engine app with public ingress rule.	An attacker might use this misconfiguration to access the application running in App Engine.
Unsupported Software	App Engine Service With Legacy Runtime	App Engine service running on legacy runtime.	Legacy runtimes support language versions that are no longer maintained by open source communities. As communities stop maintaining versions, the app may be exposed to vulnerabilities for which no publicly available fix exists.

BigQuery

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	BigQuery Dataset With Cross Project Access	A BigQuery dataset with a policy binding of a service account from a different project.	An attacker with access to the project that has access to the dataset can compromise your data.
Identity & Access Management	BigQuery Table/View With Cross Project Access	A BigQuery table or view with a policy binding of a service account from a different project.	An attacker with access to the outside service account can access this table or view and compromise your data.
Insecure Configurations	BigQuery Dataset Without Customer Managed Encryption Key (CMEK)	A BigQuery dataset without a customer-managed encryption key (CMEK).	CMEK provides more administrative control. Administrators can rotate, manage access to, and disable or destroy the key used to protect data at rest.
Insecure Configurations	BigQuery Table/View Without Customer Managed Encryption Key (CMEK)	A BigQuery Table or View without a customer-managed encryption key (CMEK).	CMEK provides more administrative control. Administrators can rotate, manage access to, and disable or destroy the key used to protect data at rest.
Public Exposure	Public BigQuery Dataset	A publicly accessible BigQuery dataset.	An attacker can access this dataset and compromise your data.
Public Exposure	Public BigQuery Table/View	A publicly accessible BigQuery table or view.	An attacker can access this table or view and compromise your data.

Bigtable

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Bigtable Instance Allows Access Of Service Account From Another Project	Bigtable instance with a policy binding of a service account from a different project.	An attacker with access from different project can compromise the environment.
Identity & Access Management	Bigtable Table Allows Access Of Service Account From Another Project	Bigtable table with a policy binding of a service account from a different project.	An attacker with access from different project can compromise the environment.
Insecure Configurations	Bigtable Cluster Without Customer Managed Encryption Key (CMEK)	Bigtable cluster configured without CMEK.	CMEK provides more administrative control. Administrators can rotate, manage access to, and disable or destroy the key used to protect data at rest.

Cloud Run

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Cloud Run Job Running with Permissive Permissions	A user / users with the roles/run.admin role can invoke or interact with the Cloud Run Job. While this approach can simplify deployment and usage, it also raises security concerns, as it may expose sensitive data or functions to potential misuse or unauthorized access.	Permissive permissions present significant security risks in cloud environments, as they can lead to unauthorized access, data breaches, and potential misuse of resources.
Identity & Access Management	Cloud Run Service Running with Permissive Permissions	A user / users with the roles/run.admin role can invoke or interact with the Cloud Run Service. While this approach can simplify deployment and usage, it also raises security concerns, as it may expose sensitive data or functions to potential misuse or unauthorized access.	Permissive permissions present significant security risks in cloud environments, as they can lead to unauthorized access, data breaches, and potential misuse of resources.
Identity & Access Management	IAM with cloud run service admin permission	A GCP identity with admin permissions to cloud run job.	An attacker with this permission has administrative access to a cloud run job.
Identity & Access Management	IAM with cloud run service admin permission	A GCP identity with admin permissions to cloud run service.	An attacker with this permission has administrative access to a cloud run service.
Identity & Access Management	Unauthenticated Invocations Allowed for Cloud Run Service	Unauthenticated invocations are enabled for this Cloud Run service. It is assigned the "allUsers" principal type with the "Cloud Run Invoker" IAM role. This effectively makes the service accessible to anyone on the internet without requiring authentication, granting anonymous access to it.	This service can be accessed by an attacker without the need for authentication. This could potentially be leveraged to exploit any vulnerabilities, resulting in a Denial of Service (DoS) attack, unauthorized extraction of sensitive data, or remote execution of commands on the underlying host.
Insecure Configurations	Binary Authorization Disabled for Cloud Run Job	Binary Authorization offers deployment control based on policies, ensuring that only trusted and verified container images are allowed for deployment.	An attacker who gains access to the Continuous Integration environment can inject malicious code or tamper with legitimate code during the build and deployment (CI-CD) process. This can introduce vulnerabilities, backdoors, or other security weaknesses into the software, which may go undetected until the compromised code is deployed.
Insecure Configurations	Binary Authorization Disabled for Cloud Run Service	Binary Authorization offers deployment control based on policies, ensuring that only trusted and verified container images are allowed for deployment.	An attacker who gains access to the Continuous Integration environment can inject malicious code or tamper with legitimate code during the build and deployment (CI-CD) process. This can introduce vulnerabilities, backdoors, or other security weaknesses into the software, which may go undetected until the compromised code is deployed.
Insecure Configurations	Cloud Run Job is Using the Compute Engine Default Service Account	Cloud Run job uses the compute engine default service account. This account is automatically created when a new project is set up By default, this service account has broad IAM permissions and it is automatically associated with every Cloud Run job.	An attacker with access to the default service account token could access each and every Cloud Run job and its associated management API operating within the same GCP project.
Insecure Configurations	Cloud Run Service is Using the Compute Engine Default Service Account	Cloud Run service uses the compute engine default service account. This account is automatically created when a new project is set up. By default, this service account has broad IAM permissions and is automatically associated with every Cloud Run service.	An attacker with access to the default service account token could access each and every Cloud Run service and its associated management API operating within the same GCP project.
Public Exposure	Cloud Run Service Publicly Accessible	This risk signifies a publicly accessible Cloud Run Service, making it accessible to any Internet user. Publicly accessible services raise the risk of unauthorized access, misuse, and breaches. The necessity of this public service should be verified; if not required, immediate action to restrict this service is advised to minimize potential security risks.	Depending on the application deployed, an attacker can exploit vulnerabilities to gain unauthorized access, manipulate and steal sensitive data, and even execute malicious actions that compromise the entire system.

Compute Engine

Category	Risk Name	Description	Attack Scenario
Credentials Exposure	Compute Engine Instance With Cleartext Chargify Key	Chargify Key Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext Jenkins Password	Jenkins Password Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext MySQL Password	MySQL Password Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext NewRelic Key	NewRelic Key Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext OAuth Key	OAuth Key Discovered in Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext Postgres Password	Postgres Password Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext RabbitMQ Password	RabbitMQ Password Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext Salesforce Credentials	Salesforce Credentials Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext Segment Token	Segment Token Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext SMTP Password	SMTP Password Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Cleartext Vero Secret	Vero Secret Discovered In Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Sensitive Generic Secret	Sensitive Generic Secret Found in Cleartext	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Credentials Exposure	Compute Engine Instance With Sensitive Generic Secret In Metadata	Sensitive Generic Secret Found in Metadata	An attacker can use the exposed keys to access unauthorized resources while bypassing existing security controls.
Identity & Access Management	IAM principal with set IAM policy permission on compute instances	A GCP Identity with permissions to set an IAM policy for compute instances.	An attacker with the setIamPolicy on a compute instance will be able to modify the IAM policy of the instance, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project instances' policies. This method could range from full access to a specific instance to full administrator access to the project.
Insecure Configurations	Compute Engine Instance With Interactive Serial Console Enabled	VM interactive serial console is enabled and does not support IP-based access restrictions.	Attacker can attempt to connect to the instance's serial console from any IP address.
Insecure Configurations	Compute Engine Instance With IP Forwarding Enabled	VM instance with a configuration that enables IP forwarding.	Attacker can attempt to send and receive packets with differenct source and destination.
Insecure Configurations	Compute Engine Instance With Project Wide SSH Keys	VM instance with a configuration that allows project-wide SSH keys.	Attacker can attempt to connect to an instance using the SSH keys configured for the project.
Insecure Configurations	Unused Compute Engine Disk	Unused disk by any instance is found.	An attacker can access the unused disk, leading to data exposure.
Unsupported Software	Deprecated Compute Engine Image
Unsupported Software	Compute Engine Instance With Deprecated Image	A deprecated image.	An attacker can exploit the deprecated image and create an instance using it.

Dataproc

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	API access to all Google Cloud services in same project is allowed	Dataproc cluster configured to allow API access to all Google Cloud services in the same project.	An attacker with access to compute engine can access google cloud services without scope limitation, leading to potentially exploit various services.
Insecure Configurations	Dataproc Cluster Without Customer Managed Encryption Key (CMEK)	A Dataproc cluser configured without CMEK.	CMEK provides more administrative control. Administrators can rotate, manage access to, and disable or destroy the key used to protect data at rest.
Public Exposure	Public Dataproc Cluster	A public Dataproc cluster.	An attacker can access Dataproc instances from the internet.
Unsupported Software	Dataproc Cluster With Unsupported Image Version	A Dataproc cluster with an unsupported image version.	An attacker can exploit known unpatched vulnerabilities in unsupported images.

Function

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Compute Engine Instance Default Service Account With Owner Role	Compute Engine default service account with owner permissions on the project.	An attacker with access to a compute engine that is attached to the default service account will have full access to the project.
Identity & Access Management	Compute Instance Default Service Account With Editor Role	Compute Engine default service account with editor permissions on the project.	An attacker with access to a compute engine that is attached to the default service account will be able to perform unauthorized actions in your project.
Identity & Access Management	Service Account With Editor Role	Service Account with editor permissions on the project.	An attacker with access to the service account will be able to perform most of the actions in the project.
Identity & Access Management	Service Account With Owner Role	Service Account with owner permissions on the project.	An attacker with access to the service account will be able to perform any action in the project.
Identity & Access Management	User With Editor Role	User with editor permissions on the project.	An attacker with access to the user will be able to perform most of the actions in the project.
Identity & Access Management	User With Owner Role	User with owner permissions on the project.	An attacker with access to the user will be able to perform any action in the project.
Insecure Configurations	Cloud Function With HTTP Only (not HTTPS)	GCP function with HTTP trigger set to require HTTP only (and not HTTPS). OWASP A6:2017 Security Misconfiguration.	An attacker can invoke the function via HTTP, gain the function app permissions and compromise your environment.
Public Exposure	Cloud Function Allows Anonymous Access	The function allows access for anonymous users. OWASP A2:2017 Broken Authentication.	An anonymous attacker can run actions against the function and might damage internal services or expose sensetive data.
Public Exposure	Cloud Function Can Be Invoked By Anonymous Users	The function can be invoked by anonymous users. OWASP A6:2017 Security Misconfiguration.	An anonymous attacker can invoke the function and might damage internal services or expose sensetive data.
Unsupported Software	GCP Function With Deprecated Runtime	GCP function with a deprecated runtime. OWASP A6:2017 Security Misconfiguration.	An attacker can exploit known unpatched vulnerabilities in the gcp function runtime.

GKE (Google Kubernetes Engine)

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	GKE Cluster is Alpha	GKE alpha cluster. OWASP K09:2022 Misconfigured Cluster Components	Alpha clusters are short-lived clusters that run stable Kubernetes releases with all Kubernetes APIs and features enabled. Alpha clusters are limited and do not receive security updates.
Insecure Configurations	GKE Cluster With Application Layer Secrets Encryption Disabled	GKE cluster with application-layer secrets encryption disabled. OWASP K08:2022 Secrets Management Failures	An attacker can gain access to an offline copy of etcd, where secrets are stored.
Insecure Configurations	GKE Cluster With Client Certificate	GKE cluster with client certificate. OWASP K06:2022 Broken Authentication Mechanisms	An attacker can use the base64 certifcate public certificate to authenticate to the cluster endpoint. Certificates do not rotate automatically. and are difficult to revoke.
Insecure Configurations	GKE Cluster With 'Cloud Logging' Option Disabled	GKE cluster with "Cloud Logging" option disabled. OWASP K05:2022 Inadequate Logging and Monitoring	Logging provides audit and diagnostic logs in your account. Collecting logs are critical for clusters as it significantly accelerates the troubleshooting process.
Insecure Configurations	GKE Cluster With 'Control plane authorized networks' Option Disabled	GKE cluster with "Control plane authorized networks" option disabled. OWASP K07:2022 Missing Network Segmentation Controls	An attacker can access the cluster's control plane endpoint through HTTPS.
Insecure Configurations	GKE Cluster With Default Service Account Attached To Node Pool	GKE cluster with a default service account attacked to the node pool. OWASP K09:2022 Misconfigured Cluster Components	By default, nodes are given the compute engine default service account. This account has more permissions than are required to run your Kubernetes Engine cluster, allowing attackers to use these permissions to compromise your environment.
Insecure Configurations	GKE Cluster With 'Legacy authorization' Option Enabled	GKE cluster with "Legacy authorization" option enabled. OWASP K06:2022 Broken Authentication Mechanisms	By default, ABAC is disabled for clusters created using GKE version 1.8 and later as RBAC has significant security advantages over ABAC.
Insecure Configurations	GKE Cluster With Network Policy Disabled	GKE cluster with network policy disabled. OWASP K07:2022 Missing Network Segmentation Controls	An attacker can access any pod in the cluster without network restrictions. Network policy is used to create Pod-level firewall rules. These firewall rules determine which Pods and Services can access one another inside your cluster.
Insecure Configurations	GKE Cluster With Shielded Nodes Disabled	GKE cluster with shielded nodes disabled. OWASP K09:2022 Misconfigured Cluster Components	An attacker can exploit a vulnerability in a Pod to exfiltrate bootstrap credentials and impersonate nodes in a cluster giving the attacker access to cluster secrets.
Insecure Configurations	GKE Cluster Without Automatic Node Upgrade	GKE cluster with no automatic node upgrade enabled. OWASP K09:2022 Misconfigured Cluster Components	Node auto-upgrades help you keep the nodes in your cluster up-to-date with the cluster control plane version when your control plane is updated on your behalf.
Insecure Configurations	GKE Cluster With 'secure boot' Option Disabled	GKE cluster with 'secure boot' option disabled. OWASP K09:2022 Misconfigured Cluster Components	Secure boot helps protect nodes against boot-level and kernel-level malware and rootkits.

KMS (Cloud Key Management)

Category	Risk Name	Description	Attack Scenario
Neglected Resource	KMS Key With Rotation Period Bigger Than 90 Days	A KMS key that has a rotation period bigger than 90 days.	Key rotation reduces the risk of a compromised key being used by an attacker to access your encrypted resources.
Public Exposure	Publicly Accessible KMS Key	A publicly accessible Cloud KMS key.	An attacker can access your KMS key. Depending on the level of access, he might be able to use the key to decrypt data and compromise it.

Memorystore

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Memorystore AUTH is Disabled	Disabling authentication (AUTH) in Memorystore allows unrestricted access to the data store, leaving it exposed to unauthorized users and increasing the risk of data breaches and tampering.	An attacker, aware that authentication (AUTH) is disabled in Memorystore, can gain unauthorized access to the data store, potentially exfiltrating sensitive data, injecting malicious content, or disrupting the service without any authentication barriers.
Insecure Configurations	Memorystore Connection by Direct Peering	Using Direct Peering establishes a direct VPC peering connection between the customer's network and Google's managed project, potentially exposing the customer's network to security risks, as this peering isn't shared with other Google Cloud services and lacks the enhanced access controls and isolation offered by Private Service Access (PSA).	An attacker monitors network traffic in the customer's VPC that uses Direct Peering to connect to Memorystore for Redis. Since Direct Peering lacks the isolation and security features of Private Service Access (PSA), the attacker can potentially eavesdrop on sensitive data transmissions, such as Redis authentication credentials or sensitive cache data, leading to data exfiltration or unauthorized access.
Insecure Configurations	Memorystore Encryption by Transit is Disabled	Disabling encryption in Memorystore's transit data transmission exposes data to potential interception, tampering, and security breaches, posing significant risks to data confidentiality and integrity.	An attacker monitoring the network traffic between a client application and a Memorystore instance with encryption in transit disabled could intercept sensitive user session data, such as login credentials, and potentially launch a man-in-the-middle attack, impersonating the client or the server, leading to data theft or manipulation.
Insecure Configurations	Memorystore Encryption without CMEK	Not having Customer Managed Encryption Keys (CMEK) in Memorystore's encryption setup leaves data encryption solely reliant on default Google-managed keys, potentially exposing sensitive data to unauthorized access and lacking the enhanced control and key management provided by CMEK.	An attacker with sufficient knowledge of Memorystore's encryption configuration without CMEK could potentially compromise the default Google-managed keys, gaining unauthorized access to the encrypted data and bypassing the additional security controls offered by customer-managed encryption keys, leading to data exposure and potential breaches.

Network Firewall

Category	Risk Name	Description	Attack Scenario
Public Exposure	Firewall Rule Permits Connections From Any IP (0.0.0.0/0)	This risk signifies a Google Cloud Platform Firewall Rule configured to allow incoming connections from any IP address, indicated by the range 0.0.0.0/0. This unrestricted access can heighten the risk of unauthorized access and potential data breaches. It's recommended to verify whether such broad access is necessary and, if not, promptly refine the access control to allow connections from specific, trusted IP addresses or ranges.	An attacker might use this misconfiguration to access assets within the GCP environment.

Project

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Compute Engine Instance Default Service Account With Owner Role	Compute Engine default service account with owner permissions on the project.	An attacker with access to a compute engine that is attached to the default service account will have full access to the project.
Identity & Access Management	Compute Instance Default Service Account With Editor Role	Compute Engine default service account with editor permissions on the project.	An attacker with access to a compute engine that is attached to the default service account will be able to perform unauthorized actions in your project.
Identity & Access Management	GKE cronJobs permissions	GKE any cronJobs permission.	An attacker can create, delete, get, list and update any cronJob.
Identity & Access Management	GKE daemonSets permissions	GKE any daemonSets permission.	An attacker can create, delete, get, list and update any daemonSets.
Identity & Access Management	GKE deployments permissions	GKE any deployments permission.	An attacker can create, delete, get, list and update any deployments.
Identity & Access Management	GKE job permissions	GKE any jobs permission.	An attacker can create, delete, get, list and update any job.
Identity & Access Management	GKE permissions to create any resource	GKE permissions to create any resource.	An attacker can create any resource in the cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to create cluster role binding	GKE permissions to create cluster role bindings.	An attacker can create cluster roles binded to a risky role, leading to cluster compromise.
Identity & Access Management	GKE permissions to create cronjobs	GKE permissions to create cronjobs.	An attacker can create cronjobs containing containers that execute malicious code within a cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to create daemonsets	GKE permissions to create daemonsets.	An attacker can create daemonsets containing containers that execute malicious code within a cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to create deployments	GKE permissions to create deployments.	An attacker can create a deployment with malicious components leading to cluster compromise.
Identity & Access Management	GKE permissions to create ingresses	GKE permissions to create ingresses.	An attacker can create risky ingresses, exposing internal services and leading to cluster compromise.
Identity & Access Management	GKE permissions to create jobs	GKE permissions to create jobs.	An attacker can create jobs containing malicious code executed within a cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to create pods	GKE permissions to create pods.	An attacker can create pods containing containers that execute malicious code within a cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to create replicasets	GKE permissions to create replicasets.	An attacker can create replicasets containing containers that execute malicious code within a cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to create replication controllers	GKE permissions to create replication controllers.	An attacker can create replication controllers containing containers that execute malicious code within a cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to create role binding	GKE permissions to create role bindings.	An attacker can create roles binded to a risky role, leading to cluster compromise.
Identity & Access Management	GKE permissions to create statefulsets	GKE permissions to create statefulsets.	An attacker can create statefulsets containing containers that execute malicious code within a cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to delete any resource	GKE permissions to delete any resource.	An attacker can delete any resource in the cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to get any resource	GKE permissions to get any resource.	An attacker can delete any resource in the cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to list any resource	GKE permissions to list any resource.	An attacker can list any resource in the cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to update cronjobs	GKE permissions to update cronjobs.	An attacker can update cronjobs to contain containers that execute malicious code within a cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to update daemonsets	GKE permissions to update daemonsets.	An attacker can update daemonsets to contain containers that execute malicious code within a cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to update deployments	GKE permissions to update deployments.	An attacker can update a deployment to contain malicious components leading to cluster compromise.
Identity & Access Management	GKE permissions to update ingresses	GKE permissions to update ingresses.	An attacker can update ingresses to expose internal services, which can lead to cluster compromise.
Identity & Access Management	GKE permissions to update jobs	GKE permissions to update jobs.	An attacker can update cronjobs to contain containers that execute malicious code within a cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to update replicasets	GKE permissions to update replicasets.	An attacker can update replicasets to contain containers that execute malicious code within a cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to update replication controllers	GKE permissions to update replication controllers.	An attacker can update replication controllers containing containers that execute malicious code within a cluster, leading to cluster compromise.
Identity & Access Management	GKE permissions to update statefulsets	GKE permissions to update statefulsets.	An attacker can update a statefulset to contain malicious components leading to cluster compromise.
Identity & Access Management	GKE pods permissions	GKE any pods permission.	An attacker can create, delete, get, list and update any pod.
Identity & Access Management	GKE replicaSets permissions	GKE any replicasets permission.	An attacker can create, delete, get, list and update any replicasets.
Identity & Access Management	GKE replicationControllers permissions	GKE any replicationControllers permission.	An attacker can create, delete, get, list and update any replicationController.
Identity & Access Management	GKE secrets permissions	GKE any secrets permission.	An attacker can create, delete, get, list and update any secret.
Identity & Access Management	GKE statefulSets permissions	GKE statefulSets permissions.	An attacker can create, delete, get, list and update any statefulSet.
Identity & Access Management	IAM principal with set IAM policy permission on compute instances	A GCP Identity with permissions to set an IAM policy for compute instances.	An attacker with the setIamPolicy on a compute instance will be able to modify the IAM policy of the instance, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project instances' policies. This method could range from full access to a specific instance to full administrator access to the project.
Identity & Access Management	IAM principal with set IAM policy permission on service accounts	A GCP Identity with permissions to set an IAM policy for service accounts.	An attacker with the setIamPolicy on a service account will be able to modify the IAM policy of the resource, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project service accounts' policies and give himself access to the strongest ones. This method could range from full access to a specific resource to full administrator access to the project depending on the permissions of the service account.
Identity & Access Management	IAM principal with set IAM policy permission on storage buckets	A GCP Identity with permissions to set an IAM policy for storage buckets.	An attacker with the setIamPolicy on a storage bucket will be able to modify the IAM policy of the bucket, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project buckets' policies. This method could range from full access to a specific bucket to full storage access to the project.
Identity & Access Management	IAM with Create cloud function with service account permission	A GCP identity with permissions to create and call a cloud function with an assigned service account.	An attacker with the iam.serviceAccounts.actAs, cloudfunctions.functions.create, cloudfunctions.functions.sourceCodeSet and cloudfunctions.functions.call permissions will be able to create a new cloud function with a specified service account. The function, when invoked, can access the metadata API and return the associated service account's access token. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions.
Identity & Access Management	IAM with Create cloud scheduler with service account permission	A GCP identity with permissions to create a cloud scheduler job.	An attacker with the iam.serviceAccounts.actAs and cloudscheduler.jobs.create permissions will be able to create jobs that send requests to *.googleapis.com endpoints. These requests can be authenticated as a specific service account. To escalate privileges with this method, the attacker needs to create an HTTP request of the action he wants to perform.
Identity & Access Management	IAM with Create compute instance with service account permission	A GCP identity with permissions to create a new compute instance with a specified service account.	An attacker with the iam.serviceAccounts.actAs and with permissions to create a new instance will be able to create an instance with a specified service account and get its access token. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions.
Identity & Access Management	IAM with Create Deployments permission	A GCP Identity with permissions to create a deployment in the deployment manager service.	An attacker with the deploymentmanager.deployments.create permission can gain the Editor role permissions on the project. This permission lets you launch new deployments of resources into GCP as the PROJECT-NUMBER@ cloudservices.gserviceaccount.com service account, which, by default, is granted the Editor role on the project.
Identity & Access Management	IAM with Create service account key permission	A GCP Identity with permissions to create a service account key.	An attacker with the iam.serviceAccountKeys.create permission can create a user-managed key for a Service Account that will allow him to access GCP as that Service Account. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions.
Identity & Access Management	IAM with Create service usage API key permission	A GCP identity with permissions to create API keys.	An attacker with the serviceusage.apiKeys.create permission will be able to create an API key, that is unrestricted by default, and use it to authenticate with GCP's APIs. By that, he can gain access to the entire GCP project.
Identity & Access Management	IAM with Create storage HMAC keys permission	A GCP identity with permission to create HMAC keys.	An attacker with the storage.hmacKeys.create permission will be able to create an hmac key for a specified service account, and use it for authentication. Depending on the service account's permissions, this method could range from no privilege escalation to full storage access.
Identity & Access Management	IAM with Get service account access token permission	A GCP Identity with permissions to get a service account's access token	An attack with the iam.serviceAccounts.getAccessToken permission will be able to get an access token that belongs to a specified service account and gain its permissions. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account.
Identity & Access Management	IAM with List service usage API keys permission	A GCP identity with permissions to get an existing API key.	An attacker with the serviceusage.apiKeys.list and apikeys.keys.getKeyString permissions will be able to get all the API keys in the project. If there is an unrestricted key, the attacker will gain full access to the project.
Identity & Access Management	IAM with Set IAM policy permission on the project	A GCP Identity with permissions to set an IAM policy for the project.	An attacker with the setIamPolicy on a project will be able to modify the IAM policy of the resource, granting himself additional privileges. This method could lead to full administrator access to the project.
Identity & Access Management	IAM with Sign service account blob permission	A GCP Identity with permission to sign a blob.	An attack with the iam.serviceAccounts.signBlob permission will be able to create a signed blob that requests an access token from a specified service account. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account.
Identity & Access Management	IAM with Sign service account JWT permission	A GCP Identity with permission to sign a JWT (JSON web token).	An attack with the iam.serviceAccounts.signJwt permission will be able to sign and request an access token of a specified service account. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account.
Identity & Access Management	IAM with Update cloud function with service account permission	A GCP identity with permissions to update an existing cloud function and its assigned service account.	An attacker with the iam.serviceAccounts.actAs, cloudfunctions.functions.update and cloudfunctions.functions.sourceCodeSet permissions will be able to update an existing cloud function and even switch its service account to a function that accesses the metadata API and retrieves the associated service account's access token. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions.
Identity & Access Management	IAM with Update IAM Role permission	A GCP Identity with permissions to update an IAM role.	An attacker with the iam.role.update permission and a custom role assigned will be able to add permissions to the role, and by that gain more privileges or even full privileges on the project.
Identity & Access Management	Service Account With Editor Role	Service Account with editor permissions on the project.	An attacker with access to the service account will be able to perform most of the actions in the project.
Identity & Access Management	Service Account With Owner Role	Service Account with owner permissions on the project.	An attacker with access to the service account will be able to perform any action in the project.
Identity & Access Management	User With Editor Role	User with editor permissions on the project.	An attacker with access to the user will be able to perform most of the actions in the project.
Identity & Access Management	User With Owner Role	User with owner permissions on the project.	An attacker with access to the user will be able to perform any action in the project.
Insecure Configurations	Project With Interactive Serial Console Enabled	Project VM interactive serial console is enabled and does not support IP-based access restrictions.	Attacker can attempt to connect to the instance's serial console from any IP address.

Pub/Sub

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Compute Engine Instance Default Service Account With Owner Role	Compute Engine default service account with owner permissions on the project.	An attacker with access to a compute engine that is attached to the default service account will have full access to the project.
Identity & Access Management	Compute Instance Default Service Account With Editor Role	Compute Engine default service account with editor permissions on the project.	An attacker with access to a compute engine that is attached to the default service account will be able to perform unauthorized actions in your project.
Identity & Access Management	Service Account With Editor Role	Service Account with editor permissions on the project.	An attacker with access to the service account will be able to perform most of the actions in the project.
Identity & Access Management	Service Account With Owner Role	Service Account with owner permissions on the project.	An attacker with access to the service account will be able to perform any action in the project.
Identity & Access Management	User With Editor Role	User with editor permissions on the project.	An attacker with access to the user will be able to perform most of the actions in the project.
Identity & Access Management	User With Owner Role	User with owner permissions on the project.	An attacker with access to the user will be able to perform any action in the project.
Insecure Configurations	Pub/Sub Topic Without Customer Managed Encryption Key (CMEK)	Pub/Sub topic without customer-managed encryption key (CMEK).	With no customer-managed encryption key (CMEK), an attacker can manage message encryption and decryption process.

IAM (Identity and Access Management)

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	IAM principal with set IAM policy permission on service accounts	A GCP Identity with permissions to set an IAM policy for service accounts.	An attacker with the setIamPolicy on a service account will be able to modify the IAM policy of the resource, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project service accounts' policies and give himself access to the strongest ones. This method could range from full access to a specific resource to full administrator access to the project depending on the permissions of the service account.
Identity & Access Management	IAM with Create service account key permission	A GCP Identity with permissions to create a service account key.	An attacker with the iam.serviceAccountKeys.create permission can create a user-managed key for a Service Account that will allow him to access GCP as that Service Account. This method could range from no privilege escalation to full access to the project, depending on the service account's permissions.
Identity & Access Management	IAM with Get service account access token permission	A GCP Identity with permissions to get a service account's access token	An attack with the iam.serviceAccounts.getAccessToken permission will be able to get an access token that belongs to a specified service account and gain its permissions. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account.
Identity & Access Management	IAM with Sign service account blob permission	A GCP Identity with permission to sign a blob.	An attack with the iam.serviceAccounts.signBlob permission will be able to create a signed blob that requests an access token from a specified service account. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account.
Identity & Access Management	IAM with Sign service account JWT permission	A GCP Identity with permission to sign a JWT (JSON web token).	An attack with the iam.serviceAccounts.signJwt permission will be able to sign and request an access token of a specified service account. Depending on the service account's permissions, this method could range from no privilege escalation to full administrator access to the account.

Cloud SQL

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Cloud PostgreSQL Instance Without 'point-in-time' Recovery	PostgreSQL instance without point-in-time recovery.	Point-in-time recovery helps you recover an instance to a specific point in time. For example, if an error causes a loss of data, you can recover a database to its state before the error occurred.
Insecure Configurations	Cloud SQL Instance Connection Logs Disabled	SQL instance without connection logs enabled.	The "log_connections" flag causes each attempted connection to the server to be logged, as well as successful completion of both client authentication (if necessary) and authorization. By default this option is set to "off", allowing attackers to login to the instance without leaving a trace.
Insecure Configurations	Cloud SQL Instance Without Automatic Backup	SQL instance without automatic backup configuration.	Backups protect your data from loss or damage.
Insecure Configurations	Cloud SQL Instance Without SSL Encryption	SQL instance without SSL encryption configured.	Unsecured connections are allowed to connect to this instance.
Insecure Configurations	GCP PostgreSQL Instance Flag 'cloudsql.allowpasswordless local_connections' is On	Setting the "cloudsql.allowpasswordless local_connections" to 'on' enables local connections without a password.	An attacker gains access to the local network and connect to a user since there is no need for a password.
Insecure Configurations	GCP PostgreSQL Instance Flag 'cloudsql.iam_authentication' is Off	Turning off 'cloudsql.iam_authentication' in GCP PostgreSQL relies solely on traditional authentication, potentially weakening IAM security integration.	An attacker who gains access to database credentials could potentially impersonate a user without the added security of IAM authentication checks. This could lead to unauthorized data access, manipulation, or even malicious actions within the database, compromising data security.
Insecure Configurations	Gcp Sql Instance Flag 'check_proxy_users' is Off	'check_proxy_users' flag off in GCP SQL risks unauthorized access by proxy users, compromising security.	An attacker who gains access to a proxy user's credentials could potentially impersonate the proxy user without proper authentication checks. This could allow the attacker to perform unauthorized actions, access sensitive data, and potentially exploit the lack of authentication verification to compromise the integrity and security of the database.
Insecure Configurations	GCP SQL Instance Flag 'default_password_lifetime' is set to 0	Setting 'default_password_lifetime' to 0 in GCP SQL risks prolonged use of unchanged passwords, heightening the potential for unauthorized access and security breaches.	An attacker could gain access to a user's password and maintain unauthorized access indefinitely without password expiration. This increases the likelihood of undetected and prolonged data breaches.
Insecure Configurations	Gcp SQL Instance Flag 'disconnect_on_expired_password' is Off	Turning 'disconnect_on_expired_password' off in GCP SQL allows users with expired passwords continued access, risking unauthorized and insecure access.	An attacker who obtains the login credentials of a user with an expired password could continue to access the database. This could lead to unauthorized data manipulation, data theft, or even malicious actions within the database, compromising data security and integrity.
Insecure Configurations	GCP SQL Instance Flag 'local_infile' is On	'local_infile' flag in GCP SQL increases risk of data exposure and unauthorized access via local file loading.	An attacker with access to the database could potentially exploit the feature to load malicious files from their local system into the database.
Insecure Configurations	GCP SQL Instance Flag 'mysqlnative_password proxy_users' is Off	This variable controls whether the mysql_native_password built-in authentication plugin supports proxy users. It has no effect unless the check_proxy_users system variable is enabled.	An attacker who gains access to a proxy user account is not authorized and connects to the account.
Insecure Configurations	GCP SQL Instance Flag 'password_require_current' is Off	A GCP SQL instance "password_require_current" flag is set to "off".	An attacker, taking advantage of the flag being off, changes a password without the need to know the old password, thereby gaining access to the account.
Insecure Configurations	GCP SQL Instance Flag 'skip_show_database' is Off	Turning 'skip_show_database' off in GCP SQL risks exposing database and schema details, facilitating unauthorized enumeration and targeted attacks.	An attacker could potentially use the SHOW DATABASES command to enumerate available databases and gain insights into the database schema. This knowledge could aid them in crafting more effective and targeted attacks.
Insecure Configurations	GCP SQL is Not Using CMK	GCP SQL instance without CMK.	In a scenario where a GCP SQL instance is not using Customer-Managed Keys (CMK), an attacker who gains unauthorized access to Google's managed encryption keys or exploits vulnerabilities in Google's key management infrastructure could potentially decrypt and access sensitive data stored in the SQL database, leading to data breaches and confidentiality breaches.
Insecure Configurations	GCP SQL Without Password Policy	No password policy in GCP SQL increases the risk of weak passwords and unauthorized access, compromising data security.	An attacker could potentially perform brute-force attacks or use common passwords to guess weak passwords associated with the database, granting them unauthorized access to the data and compromising the security and integrity of the system.
Public Exposure	Cloud SQL Instance Allows Network Connection From Any IP (0.0.0.0/0)	SQL instance with an authorized network of 0.0.0.0/0	This prefix will allow any IPv4 client to pass the network firewall and make login attempts to your instance, including clients you did not intend to allow.
Public Exposure	GCP SQL is Not Using Private Ip	GCP SQL instance is Not Using Private Ip.	Without a private IP in GCP SQL, an attacker could potentially intercept sensitive database traffic over the public network, leading to data exposure.

Storage Bucket

Category	Risk Name	Description	Attack Scenario
Data Security	Cloud Storage Bucket Contains Potentially Public Objects	This risk identifies a Google Cloud Storage bucket that contains objects that may be publicly accessible, thereby potentially enabling any internet user to access them. Potentially shared objects in a storage bucket can heighten the risk of unauthorized data access and potential data breaches. It's recommended to review these objects and their access controls, and if public access is not required, promptly update their permissions to secure your data.	An attacker can maybe access some objects in the bucket leading to data exposure.
Data Security	Storage Bucket Publicly Accessible	This risk points to a Google Cloud Storage bucket configured as publicly accessible, potentially making it reachable by any internet user. Publicly accessible storage buckets can significantly increase the risk of unauthorized data access and potential data breaches. It's recommended to verify whether such public access is necessary and, if not, promptly restrict access to strengthen your data security.	An attacker can access this bucket and compromise your data.
Data Security	Storage Bucket Without Encryption	This risk signifies a Google Cloud Storage bucket that lacks encryption, a critical security measure to protect sensitive data from unauthorized access. Unencrypted Storage buckets can raise the risk of data exposure or misuse. It's strongly advised to enable encryption to safeguard your data and comply with security best practices and regulations.	An attacker can access this bucket and compromise your data
Identity & Access Management	IAM principal with set IAM policy permission on storage buckets	A GCP Identity with permissions to set an IAM policy for storage buckets.	An attacker with the setIamPolicy on a storage bucket will be able to modify the IAM policy of the bucket, granting himself additional privileges at the resource level. If this permission is given at the project level, the attacker will be able to change all the project buckets' policies. This method could range from full access to a specific bucket to full storage access to the project.
Identity & Access Management	Service Account With Editor Role	Service Account with editor permissions on the project.	An attacker with access to the service account will be able to perform most of the actions in the project.
Identity & Access Management	Service Account With Owner Role	Service Account with owner permissions on the project.	An attacker with access to the service account will be able to perform any action in the project.
Identity & Access Management	User With Editor Role	User with editor permissions on the project.	An attacker with access to the user will be able to perform most of the actions in the project.
Identity & Access Management	User With Owner Role	User with owner permissions on the project.	An attacker with access to the user will be able to perform any action in the project.

Oracle Cloud Infrastructure (OCI) - click to collapse

Oracle Cloud Infrastructure (OCI)

Click on a service name below to view a table of the risks Panoptica detects in OCI, along with brief descriptions and attack scenarios.

DB System

Category	Risk Name	Description	Attack Scenario
Data Security	Oracle Autonomous Databases Publicly Accessible	Autonomous database with a cidr address of 0.0.0.0/0.	An attacker might be able to access the database from any IP address.
Data Security	Oracle Database Auto Backup Disabled	Database without automatic backup configuration.	It is a best practice to enable continuous backups for your databases.
Data Security	Oracle Database Without Encryption	Unencrypted database.	An attacker can access the data stored in your database.
Insecure Configurations	Autonomous Oracle Database Without mTLS	mTLS is not required for the database.	mTLS helps ensure that traffic is secure and trusted in both directions between a client and server.

Policy

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Administator permissions over tenancy	Administator access over tenancy.	An attacker with administrator permissions can perform any action on any resource in the environment.
Identity & Access Management	Manage cluster-family permission in compartment	Permission to manage cluster-family in compartment.	An attacker with manage cluster-family access has full access to container engine for kubernetes resources in the compartment.
Identity & Access Management	Manage cluster-family permission in tenancy	Permission to manage cluster-family in tenancy.	An attacker with manage cluster-family access has full access to container engine for kubernetes resources in tenancy.
Identity & Access Management	Manage database-family permission in compartment	Permission to manage database-family in compartment.	An attacker with manage database-family access has full access to database resources in the compartment.
Identity & Access Management	Manage database-family permission in tenancy	Permission to manage database-family in tenancy.	An attacker with manage database-family access has full access to database resources in tenancy.
Identity & Access Management	Manage DNS permission in compartment	Permission to manage DNS in compartment.	An attacker with manage DNS access has full access to DNS resources in the compartment.
Identity & Access Management	Manage DNS permission in tenancy	Permission to manage DNS in tenancy.	An attacker with manage DNS access has full access to DNS resources in tenancy.
Identity & Access Management	Manage instance-family permission in compartment	Permission to manage instance-family in compartment.	An attacker with manage instance-family access has full access to instance resources in the compartment.
Identity & Access Management	Manage instance-family permission in tenancy	Permission to manage instance-family in tenancy.	An attacker with manage instance-family access has full access to instance resources in tenancy.
Identity & Access Management	Manage object-family permission in compartment	Permission to manage object-family in compartment.	An attacker with manage object-family access has full access to bucket and object resources in the compartment.
Identity & Access Management	Manage object-family permission in tenancy	Permission to manage object-family in tenancy.	An attacker with manage object-family access has full access to buckets and objects resources in tenancy.
Identity & Access Management	Manage policies permission in tenancy	Permission to manage policies in tenancy.	An attacker with 'manage' permission over policies in the tenancy can exploit this permission and perform privilege escalation by creating a policy with higher permissions and assign its group to be part of it.
Identity & Access Management	Manage users permission in tenancy	Permission to manage users in tenancy.	An attacker with 'manage' users permission can perform any action on users in the environment such as resetting passwords, leading to privilege escalation.
Identity & Access Management	Use all resources permission in tenancy	Permission to use all resources in tenancy.	An attacker with 'use' permission over all resources in the tenancy can exploit this permission and perform privilege escalation.

Storage Bucket

Category	Risk Name	Description	Attack Scenario
Data Security	Object Storage Bucket Publicly Accessible	This risk identifies an Oracle Cloud Storage bucket configured to be publicly accessible, potentially making it reachable by any internet user. Publicly accessible buckets significantly raise the risk of unauthorized data access and potential data breaches. It's recommended to ascertain the necessity of such public access, and if it's not required, promptly restrict access to bolster your data security.	An attacker can access the bucket and objects leading to data exposure.
Data Security	Object Storage Bucket Without Encryption	This risk indicates an Oracle Cloud Storage bucket not configured for encryption, a vital security measure to safeguard sensitive data from unauthorized access. Unencrypted buckets can increase the risk of data exposure or misuse. It's strongly recommended to enable encryption to secure your data and adhere to security best practices and compliance regulations.	An attacker can access this bucket and compromise stored data.

User

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	User Without MFA	This risk highlights an Oracle Cloud user who doesn't have Multi-Factor Authentication (MFA) enabled. MFA offers an added layer of security by requiring more than just a password for user authentication. An absence of MFA exposes the user's account to a heightened risk of unauthorized access. It's strongly advised to enable MFA for all users to strengthen account security within Oracle Cloud.	An attacker can bypass authentication with a password only.

Kubernetes - click to collapse

Kubernetes

Click on a service name below to view a table of the risks Panoptica detects in Kubernetes clusters, along with brief descriptions and attack scenarios.

Cluster Role

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Cluster Role With Attach Pods Permissions	OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create CronJobs Permissions	A cluster role that allows to create cronjobs in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create DaemonSets Permissions	A cluster role that allows to create daemonsets in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create Deployments Permissions	A cluster role that allows to create deployments in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create Jobs Permissions	A cluster role that allows to create jobs in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create Mutating Webhook Configuration Permissions	A cluster role that allows create mutating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
Identity & Access Management	Cluster Role with Create or Wildcard Permissions to the LocalSubjectAccessReview Resource	A Cluster role with Create or Wildcard Permissions to the LocalSubjectAccessReview Resource.	An attacker with access to this cluster role can map users and their associated permissions within a namespace in the cluster.
Identity & Access Management	Cluster Role with Create or Wildcard Permissions to the SubjectAccessReview Resource	A Cluster role with Create or Wildcard Permissions to the SubjectAccessReview Resource.	An attacker with access to this cluster role can map users and their associated permissions within the cluster.
Identity & Access Management	Cluster Role with Create or Wildcard Permissions to the TokenRequest Resource	A Cluster role with Create or Wildcard Permissions to the TokenRequest Resource.	An attacker with access to this cluster role can request tokens for any service account in the cluster. Service account tokens are used to authenticate requests to the Kubernetes API server, and if an attacker has access to those tokens, they can use them to impersonate service accounts and gain access to privileged resources and actions. This could give the attacker the ability to modify or delete any resource in the cluster, potentially leading to a full compromise of the cluster.
Identity & Access Management	Cluster Role With Create ReplicaSets Permissions	A cluster role that allows to create replicasets in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create Replication Controllers Permissions	A cluster role that allows to create replicationcontrollers in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create RoleBinding Permissions	A cluster role that allows to create a role binding to any role in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker can leverage this permission to create a binding between its identity and a strong role in the cluster.
Identity & Access Management	Cluster Role With Create RoleBinding/ClusterRoleBinding Permissions	A cluster role in Kubernetes with permission to create a cluster role binding.OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker with access to that cluster role can escalate his privileges by binding the service account or user to the cluster-admin cluster role or a different cluster role with higher permissions.
Identity & Access Management	Cluster Role With Create StatefulSets Permissions	A cluster role that allows to create statefulsets in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Create Validating Webhook Configuration Permissions	A cluster role that allows create validating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
Identity & Access Management	Cluster Role With Delete Deployments Permissions	A cluster role that allows to delete deployments in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Delete Mutating Webhook Configuration Permissions	A cluster role that allows delete mutating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
Identity & Access Management	Cluster Role With Delete Namespaces Permissions	Cluster role with delete namespaces in cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	Attacker with delete namespace permission can delete any namespace in the cluster include the running pods in the namespace.
Identity & Access Management	Cluster Role With Delete Validating Webhook Configuration Permissions	A cluster role that allows delete validating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
Identity & Access Management	Cluster Role With Delete/DeleteCollection Secrets Permissions	A cluster role that allows to delete or deletecollection secrets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Exec Pods Permissions	OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role with Full Permissions to any Resources on Non-K8s Core or Wildcard API Groups	A cluster role has full permissions for any resource on API groups other than wildcard or the K8s core API.	An attacker with access to this cluster role can perform any action against the API groups defined in this cluster role. Possibly escalate his privileges and move laterally within the cluster.
Identity & Access Management	Cluster Role with Get and Create Permissions to the Nodes/Proxy Resource	A cluster role with Get and Create permissions to the nodes/proxy resource.	An attacker that has access to a principal with the Get, Create permissions on the nodes/proxy resource can communicate with the Node’s Kubelet API directly and possibly escalate it's privileges to a cluster admin.
Identity & Access Management	Cluster Role With Patch Mutating Webhook Configuration Permissions	Cluster role with patch mutating webhook configuration in cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
Identity & Access Management	Cluster Role With Patch Validating Webhook Configuration Permissions	Cluster role with patch validating webhook configuration in cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
Identity & Access Management	Cluster Role with Permissions to Change Configmaps	A cluster role that allows to update or patch configmaps in the cluster.	An attacker with access to this cluster role can alter configmaps in the cluster.
Identity & Access Management	Cluster Role with Permissions to Change Service Accounts	A cluster role with permissions to change service accounts.	An attacker with access to this cluster role can alter service accounts in the cluster.
Identity & Access Management	Cluster Role with Permissions to Create Configmaps	A cluster role that allows to create configmaps in the cluster.	An attacker with access to this cluster role can create configmaps in the cluster.
Identity & Access Management	Cluster Role with Permissions to Create Nodes	A cluster role with permissions to create nodes.	An attacker with access to this cluster role can create nodes in the cluster.
Identity & Access Management	Cluster Role with Permissions to Create Service Accounts	A cluster role with permissions to create service accounts.	An attacker with access to this cluster role can create service acconts in the cluster.
Identity & Access Management	Cluster Role with Permissions to Delete Configmaps	A cluster role that allows to delete configmaps in the cluster.	An attacker with access to this cluster role can delete configmaps in the cluster.
Identity & Access Management	Cluster Role with Permissions to Delete Nodes	A cluster role with permissions to delete nodes.	An attacker with access to this cluster role can delete nodes in the cluster.
Identity & Access Management	Cluster Role with Permissions to Delete Service Accounts	A cluster role with permissions to delete service accounts.	An attacker with access to this cluster role can delete service accounts in the cluster.
Identity & Access Management	Cluster Role with Permissions to Read Configmaps	A cluster role with permissions to read or list Configmaps.	An attack with access to this cluster role can read or list configmaps in the cluster.
Identity & Access Management	Cluster Role with Permissions to Read Service Accounts	A cluster role with permissions to read service accounts.	An attacker with access to this cluster role can read service accounts in the cluster.
Identity & Access Management	Cluster Role with Permissions to Update Nodes	A cluster role with permissions to update nodes.	An attacker with access to this cluster role can update nodes in the cluster.
Identity & Access Management	Cluster Role With Update CronJobs Permissions	A cluster role that allows to update cronjobs in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update DaemonSets Permissions	A cluster role that allows to update daemonsets in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update Deployments Permissions	A cluster role that allows to update deployments in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update Jobs Permissions	A cluster role that allows to update jobs in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update ReplicaSets Permissions	A cluster role that allows to update replicasets in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update Replication Controllers Permissions	A cluster role that allows to update replicationcontrollers in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update StatefulSets Permissions	A cluster role that allows to update statefulsets in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Update\Patch Secrets Permissions	A cluster role that allows to update or patch secrets in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With View Secrets Permissions	A cluster role that allows to list and view all secrets in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations	Once there is a single account in the cluster with the cluster-admin role binding, an attacker with access to that cluster role can steal the admin’s token and escalate his privileges to the highest cluster privileges.
Identity & Access Management	Cluster Role With View Secrets Permissions	A cluster role that allows to get any secret in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker can leverage this permission to obtain a secret value and move lateraly inside the cluster.
Identity & Access Management	Cluster Role With Wildcard Create Permissions	A cluster role that allows to create any resource in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard CronJobs Permission	A cluster role that allows to perform any action on cronjobs in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard DaemonSets Permissions	A cluster role that allows to perform any action on daemonsets in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Delete Collection Permissions	A cluster role that allows to deletecollection of any resource in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Delete Permissions	A cluster role that allows to delete any resource in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Deployments Permissions	A cluster role that allows to perform any action on deployments in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Impersonate Permissions	A cluster role that allows to impersonate any resource in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Jobs Permission	A cluster role that allows to perform any action on jobs in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard List Permissions	A cluster role that allows to list any resource in the Kubernetes cluster, including secrets.OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker with access to this cluster role can escalate privileges by listing powerful secrets and using their value. It is possible to obtain a secret token belongs to a service account with cluster-admin privileges.
Identity & Access Management	Cluster Role With Wildcard Mutating Webhook Configurations Permissions	A cluster role that allows any action on mutating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations	An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized
Identity & Access Management	Cluster Role with Wildcard Permissions to any Resources on Non-K8s Core or Wildcard API Groups	A cluster role with wildcard permissions for any resource on API groups other than wildcard or the K8s core API.	An attacker with access to this cluster role can perform any action against the API groups defined in this cluster role. Possibly escalate his privileges and move laterally within the cluster.
Identity & Access Management	Cluster Role With Wildcard Pods Permissions	A cluster role that allows to perform any action on pods in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard ReplicaSets Permission	A cluster role that allows to perform any action on replicasets in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Replication Controllers Permission	A cluster role that allows to perform any action on replicationcontrollers in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Secrets Permissions	A cluster role with a wildcard in the verbs section on secrets resource.OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker with access to that cluster role can view or edit all secrets in the cluster, and escalate his privileges using different methods to take over the cluster control by getting an admin secret.
Identity & Access Management	Cluster Role With Wildcard StatefulSets Permissions	A cluster role that allows to perform any action on statefulsets in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Validating Webhook Configurations Permissions	A cluster role that allows any action on validating webhook configurations resource in the cluster. OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	Cluster Role With Wildcard Verbs Permissions	A cluster role with a wildcard in the verbs section.OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker with access to that cluster role can execute any action against the resources defined in that cluster role, and escalate his privileges using different methods to take over the cluster control.
Identity & Access Management	Cluster Role With Wildcard View Permissions	A cluster role that allows to get any resource in the cluster.OWASP K03:2022 Overly Permissive RBAC Configurations
Identity & Access Management	User With Impersonate Group Permissions	A user with permission to Impersonate a group.OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker with access to a service account with permissions to impersonate a privileged group may escalate his privileges to gain higher access permissions in the cluster.

Cluster Role Binding

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Cluster Role Binding Allows Unauthenticated Access	ClusterRoleBinding with 'system:unauthenticated' group allow to users are related to this group to perform the actions in the matched role. OWASP K03:2022 Overly Permissive RBAC Configurations	Attacker can perform action in the cluster without to authenticate.
Identity & Access Management	Cluster role binding of service account to wildcard cluster role	OWASP K03:2022 Overly Permissive RBAC Configurations

Deployment

Category	Risk Name	Description	Attack Scenario
Insecure Configurations	Kubernetes Dashboard With 'enable-skip-login'' Enabled	Kubernetes-dashboard was found with an "enable-skip-login" parameter enabled.While this parameter is enabled, Users can access the Kubernetes-dashboard without providing authentication details.OWASP K09:2022 Misconfigured Cluster Components	An attacker with network access to the Kubernetes-dashboard can take advantage of this configuration and get information about the cluster and its workloads.

Pod

Category	Risk Name	Description	Attack Scenario
Credentials Exposure	Container With Mounted Secret	K8s secret is mounted inside a container path.OWASP K01:2022 Insecure Workload Configurations	An attacker might use the secret value to lateraly move inside the K8s cluster.
Insecure Configurations	Container Running As Root Group	Container running as root group.OWASP K01:2022 Insecure Workload Configurations	An attacker with access to the container can use different methods to escape the container and have root privileges on the host.
Insecure Configurations	Container Running As Root User	Container running as root user.OWASP K01:2022 Insecure Workload Configurations	An attacker with access to the container can use different methods to escape the container and have root privileges on the host.
Insecure Configurations	Container With '/etc' Path Mounted	A container with a risky hostPath mount - mount to the /etc folder in the host filesystem.OWASP K01:2022 Insecure Workload Configurations	An attacker with access to that container can access the host's sensitive information and secret configuration in the host filesystem.
Insecure Configurations	Container With '/root' Path Mounted	A container with a risky hostPath mount - mount to the host /root folder.OWASP K01:2022 Insecure Workload Configurations	An attacker with access to that container can access the host's sensitive information and other containers running on the same host.
Insecure Configurations	Container With '/var' Path Mounted	A container with a risky hostPath mount - mount to the host /var folder.OWASP K01:2022 Insecure Workload Configurations	An attacker with access to that container can access the host's sensitive information and other containers running on the same host.
Insecure Configurations	Container With '/var/lib/kubelet/pods' Path Mounted	A container with a risky hostPath mount - mount to the host /var/lib folder.OWASP K01:2022 Insecure Workload Configurations	An attacker with access to that container can access the host's sensitive information and other containers running on the same host.
Insecure Configurations	Container With AllowPrivilegeEscalation	Container running with AllowPrivilegeEscalation flag set to true.OWASP K01:2022 Insecure Workload Configurations	The allowPrivilegeEscalation is part of the Pod Security Policy Parameters. The allowPrivilegeEscalation Gates whether or not a user is allowed to set the security context to allowPrivilegeEscalation=true in a container. This defaults to allowed so as not to break setuid binaries. An attacker with access to the container can gain more privileges than the container parent.
Insecure Configurations	Container With Full File System Mounted	A container with mount of root directory.OWASP K01:2022 Insecure Workload Configurations	An attacker with access to that container can access the host and escape the container to gain higher privileges.
Insecure Configurations	Container With Privileged Mode	Container running in privileged mode.OWASP K01:2022 Insecure Workload Configurations	An attacker with access to the container can access all devices on the host.
Insecure Configurations	Container With Risky Path Mounted	A container with a risky hostPath mount - mount to the azure.json file.OWASP K01:2022 Insecure Workload Configurations	An attacker with access to that container can access the host configuration file and use its service principal credentials to escalate his Azure subscription privileges.
Insecure Configurations	Container With CAP_SYS_ADMIN+K60	Container with CAP_SYS_ADMIN capability.OWASP K01:2022 Insecure Workload Configurations	CAP_SYS_ADMIN its capability that allow some sensetive action like mount, without any enabled security application attacker can get access to the host.
Insecure Configurations	Container Without Protection Against Root Privileged	Pod configuration without limition of user permission. No definition of runAsUser and runAsNonRoot values in securityContext.OWASP K01:2022 Insecure Workload Configurations	Attacker with access to the cluser can execute command inside container with root permmisions, also attacker can leverege his permissions to container escapes.
Insecure Configurations	Container Without Read Only Filesystem	Container without read-only file system. Read-only filesystems are a key component to preventing container breakout.OWASP K01:2022 Insecure Workload Configurations	A malicious process or application can write back to the host system.
Insecure Configurations	ContainerÂ Without Resource Limits	A container without resource limits.OWASP K01:2022 Insecure Workload Configurations	An attacker with access to a container without resource limits may cause a denial of service for the hosts it's running on.
Insecure Configurations	Pod With Apparmor Disabled	OWASP K01:2022 Insecure Workload Configurations
Insecure Configurations	Pod With 'docker.sock' Mounted	Container with docker.sock mounted.OWASP K01:2022 Insecure Workload Configurations	Attacker with access to container that has docker.sock mounted can run any container on the node, perform container escape, privilege escalation or lateral movements.
Insecure Configurations	Pod With Full Capabilities	Pod gets all capabilities. OWASP K01:2022 Insecure Workload Configurations	Attacker with access to pod with all capabilities can leverage for container escape.
Insecure Configurations	Pod With Log4j Vulnerable Hotpatch	AWS Hotpatch for Log4j Vulnerablity. This Hotpatch could be leveraged for container escape and privileged escalation OWASP K10:2022 Outdated and Vulnerable Kubernetes Components	An attacker can perform conainer escape and get access to underlying host from every container in your cluster. Also, unprivileged processes can exploit the Hotpatch to escalate privileges and gain root code execution.

Role

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Cluster Role With View Secrets Permissions In Namespace	A role that allows to get secrets in the namespace.OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker can leverage this permission to obtain a secret value and move lateraly inside the cluster.
Identity & Access Management	Role With Admin Permissions	A role with a wildcard in the verbs section.OWASP K03:2022 Overly Permissive RBAC Configurations	An attacker with access to that role can execute any action against the resources defined in that role, and escalate his privileges using different methods in the namespace.

Role Binding

Category	Risk Name	Description	Attack Scenario
Identity & Access Management	Role Binding Allows Anonymous Access	RoleBinding with 'system:anonymous' user allow to unauthenticated users to perform the actions in the role.	Attacker can perform action in the specific namespace without to authenticate.
Identity & Access Management	Role Binding Allows Unauthenticated Access	RoleBinding with 'system:unauthenticated' group allow to users are related to this group to perform the actions in the matched role. OWASP K03:2022 Overly Permissive RBAC Configurations	Attacker can perform action in the specific namespace without to authenticate.
Identity & Access Management	Role Binding To Default Service Account	OWASP K03:2022 Overly Permissive RBAC Configurations