diff --git a/dashboard/compliance/prowler_threatscore_aws.py b/dashboard/compliance/prowler_threatscore_aws.py new file mode 100644 index 0000000000..94558f33ad --- /dev/null +++ b/dashboard/compliance/prowler_threatscore_aws.py @@ -0,0 +1,24 @@ +import warnings + +from dashboard.common_methods import get_section_containers_cis + +warnings.filterwarnings("ignore") + + +def get_table(data): + aux = data[ + [ + "REQUIREMENTS_ID", + "REQUIREMENTS_DESCRIPTION", + "REQUIREMENTS_ATTRIBUTES_SECTION", + "CHECKID", + "STATUS", + "REGION", + "ACCOUNTID", + "RESOURCEID", + ] + ].copy() + + return get_section_containers_cis( + aux, "REQUIREMENTS_ID", "REQUIREMENTS_ATTRIBUTES_SECTION" + ) diff --git a/dashboard/compliance/prowler_threatscore_azure.py b/dashboard/compliance/prowler_threatscore_azure.py new file mode 100644 index 0000000000..94558f33ad --- /dev/null +++ b/dashboard/compliance/prowler_threatscore_azure.py @@ -0,0 +1,24 @@ +import warnings + +from dashboard.common_methods import get_section_containers_cis + +warnings.filterwarnings("ignore") + + +def get_table(data): + aux = data[ + [ + "REQUIREMENTS_ID", + "REQUIREMENTS_DESCRIPTION", + "REQUIREMENTS_ATTRIBUTES_SECTION", + "CHECKID", + "STATUS", + "REGION", + "ACCOUNTID", + "RESOURCEID", + ] + ].copy() + + return get_section_containers_cis( + aux, "REQUIREMENTS_ID", "REQUIREMENTS_ATTRIBUTES_SECTION" + ) diff --git a/dashboard/compliance/prowler_threatscore_gcp.py b/dashboard/compliance/prowler_threatscore_gcp.py new file mode 100644 index 0000000000..94558f33ad --- /dev/null +++ b/dashboard/compliance/prowler_threatscore_gcp.py @@ -0,0 +1,24 @@ +import warnings + +from dashboard.common_methods import get_section_containers_cis + +warnings.filterwarnings("ignore") + + +def get_table(data): + aux = data[ + [ + "REQUIREMENTS_ID", + "REQUIREMENTS_DESCRIPTION", + "REQUIREMENTS_ATTRIBUTES_SECTION", + "CHECKID", + "STATUS", + "REGION", + "ACCOUNTID", + "RESOURCEID", + ] + ].copy() + + return get_section_containers_cis( + aux, "REQUIREMENTS_ID", "REQUIREMENTS_ATTRIBUTES_SECTION" + ) diff --git a/dashboard/pages/compliance.py b/dashboard/pages/compliance.py index 422e801503..d9c5c9f4b0 100644 --- a/dashboard/pages/compliance.py +++ b/dashboard/pages/compliance.py @@ -398,6 +398,10 @@ def display_data( f"dashboard.compliance.{current}" ) data.drop_duplicates(keep="first", inplace=True) + + if "threatscore" in analytics_input: + data = get_threatscore_mean_by_pillar(data) + table = compliance_module.get_table(data) except ModuleNotFoundError: table = html.Div( @@ -430,6 +434,9 @@ def display_data( if "pci" in analytics_input: pie_2 = get_bar_graph(df, "REQUIREMENTS_ID") current_filter = "req_id" + elif "threatscore" in analytics_input: + pie_2 = get_table_prowler_threatscore(df) + current_filter = "threatscore" elif ( "REQUIREMENTS_ATTRIBUTES_SECTION" in df.columns and not df["REQUIREMENTS_ATTRIBUTES_SECTION"].isnull().values.any() @@ -488,6 +495,13 @@ def display_data( pie_2, f"Top 5 failed {current_filter} by requirements" ) + if "threatscore" in analytics_input: + security_level_graph = get_graph( + pie_2, + "Pillar Score by requirements (1 = Lowest Risk, 5 = Highest Risk)", + margin_top=0, + ) + return ( table_output, overall_status_result_graph, @@ -501,7 +515,7 @@ def display_data( ) -def get_graph(pie, title): +def get_graph(pie, title, margin_top=7): return [ html.Span( title, @@ -514,7 +528,7 @@ def get_graph(pie, title): "display": "flex", "justify-content": "center", "align-items": "center", - "margin-top": "7%", + "margin-top": f"{margin_top}%", }, ), ] @@ -618,3 +632,87 @@ def get_table(current_compliance, table): className="relative flex flex-col bg-white shadow-provider rounded-xl px-4 py-3 flex-wrap w-full", ), ] + + +def get_threatscore_mean_by_pillar(df): + modified_df = df[df["STATUS"] == "FAIL"] + + modified_df["REQUIREMENTS_ATTRIBUTES_LEVELOFRISK"] = pd.to_numeric( + modified_df["REQUIREMENTS_ATTRIBUTES_LEVELOFRISK"], errors="coerce" + ) + + pillar_means = ( + modified_df.groupby("REQUIREMENTS_ATTRIBUTES_SECTION")[ + "REQUIREMENTS_ATTRIBUTES_LEVELOFRISK" + ] + .mean() + .round(2) + ) + + output = [] + for pillar, mean in pillar_means.items(): + output.append(f"{pillar} - [{mean}]") + + for value in output: + if value.split(" - ")[0] in df["REQUIREMENTS_ATTRIBUTES_SECTION"].values: + df.loc[ + df["REQUIREMENTS_ATTRIBUTES_SECTION"] == value.split(" - ")[0], + "REQUIREMENTS_ATTRIBUTES_SECTION", + ] = value + return df + + +def get_table_prowler_threatscore(df): + df = df[df["STATUS"] == "FAIL"] + + # Delete " - " from the column REQUIREMENTS_ATTRIBUTES_SECTION + df["REQUIREMENTS_ATTRIBUTES_SECTION"] = ( + df["REQUIREMENTS_ATTRIBUTES_SECTION"].str.split(" - ").str[0] + ) + + df["REQUIREMENTS_ATTRIBUTES_LEVELOFRISK"] = pd.to_numeric( + df["REQUIREMENTS_ATTRIBUTES_LEVELOFRISK"], errors="coerce" + ) + + score_df = ( + df.groupby("REQUIREMENTS_ATTRIBUTES_SECTION")[ + "REQUIREMENTS_ATTRIBUTES_LEVELOFRISK" + ] + .mean() + .reset_index() + .rename( + columns={ + "REQUIREMENTS_ATTRIBUTES_SECTION": "Pillar", + "REQUIREMENTS_ATTRIBUTES_LEVELOFRISK": "Score", + } + ) + ) + + fig = px.bar( + score_df, + x="Pillar", + y="Score", + color="Score", + color_continuous_scale=[ + "#45cc6e", + "#f4d44d", + "#e77676", + ], # verde → amarillo → rojo + hover_data={"Score": True, "Pillar": True}, + labels={"Score": "Average Risk Score", "Pillar": "Section"}, + height=400, + ) + + fig.update_layout( + xaxis_title="Pillar", + yaxis_title="Level of Risk", + margin=dict(l=20, r=20, t=30, b=20), + plot_bgcolor="rgba(0,0,0,0)", + paper_bgcolor="rgba(0,0,0,0)", + coloraxis_colorbar=dict(title="Risk"), + ) + + return dcc.Graph( + figure=fig, + style={"height": "25rem", "width": "40rem"}, + ) diff --git a/prowler/CHANGELOG.md b/prowler/CHANGELOG.md index ca04641ce4..be40fe2cdb 100644 --- a/prowler/CHANGELOG.md +++ b/prowler/CHANGELOG.md @@ -35,6 +35,7 @@ All notable changes to the **Prowler SDK** are documented in this file. - Add new check `teams_meeting_recording_disabled` [(#7607)](https://github.com/prowler-cloud/prowler/pull/7607) - Add new check `teams_meeting_presenters_restricted` [(#7613)](https://github.com/prowler-cloud/prowler/pull/7613) - Add new check `teams_meeting_chat_anonymous_users_disabled` [(#7579)](https://github.com/prowler-cloud/prowler/pull/7579) +- Add Prowler Threat Score Compliance Framework [(#7603)](https://github.com/prowler-cloud/prowler/pull/7603) ### Fixed diff --git a/prowler/__main__.py b/prowler/__main__.py index 13b430e764..b201268da3 100644 --- a/prowler/__main__.py +++ b/prowler/__main__.py @@ -70,6 +70,15 @@ from prowler.lib.outputs.compliance.mitre_attack.mitre_attack_azure import ( AzureMitreAttack, ) from prowler.lib.outputs.compliance.mitre_attack.mitre_attack_gcp import GCPMitreAttack +from prowler.lib.outputs.compliance.prowler_threatscore.prowler_threatscore_aws import ( + ProwlerThreatScoreAWS, +) +from prowler.lib.outputs.compliance.prowler_threatscore.prowler_threatscore_azure import ( + ProwlerThreatScoreAzure, +) +from prowler.lib.outputs.compliance.prowler_threatscore.prowler_threatscore_gcp import ( + ProwlerThreatScoreGCP, +) from prowler.lib.outputs.csv.csv import CSV from prowler.lib.outputs.finding import Finding from prowler.lib.outputs.html.html import HTML @@ -478,6 +487,18 @@ def prowler(): ) generated_outputs["compliance"].append(kisa_ismsp) kisa_ismsp.batch_write_data_to_file() + elif compliance_name == "prowler_threatscore_aws": + filename = ( + f"{output_options.output_directory}/compliance/" + f"{output_options.output_filename}_{compliance_name}.csv" + ) + prowler_threatscore = ProwlerThreatScoreAWS( + findings=finding_outputs, + compliance=bulk_compliance_frameworks[compliance_name], + file_path=filename, + ) + generated_outputs["compliance"].append(prowler_threatscore) + prowler_threatscore.batch_write_data_to_file() else: filename = ( f"{output_options.output_directory}/compliance/" @@ -545,6 +566,18 @@ def prowler(): ) generated_outputs["compliance"].append(iso27001) iso27001.batch_write_data_to_file() + elif compliance_name == "prowler_threatscore_azure": + filename = ( + f"{output_options.output_directory}/compliance/" + f"{output_options.output_filename}_{compliance_name}.csv" + ) + prowler_threatscore = ProwlerThreatScoreAzure( + findings=finding_outputs, + compliance=bulk_compliance_frameworks[compliance_name], + file_path=filename, + ) + generated_outputs["compliance"].append(prowler_threatscore) + prowler_threatscore.batch_write_data_to_file() else: filename = ( f"{output_options.output_directory}/compliance/" @@ -612,6 +645,18 @@ def prowler(): ) generated_outputs["compliance"].append(iso27001) iso27001.batch_write_data_to_file() + elif compliance_name == "prowler_threatscore_gcp": + filename = ( + f"{output_options.output_directory}/compliance/" + f"{output_options.output_filename}_{compliance_name}.csv" + ) + prowler_threatscore = ProwlerThreatScoreGCP( + findings=finding_outputs, + compliance=bulk_compliance_frameworks[compliance_name], + file_path=filename, + ) + generated_outputs["compliance"].append(prowler_threatscore) + prowler_threatscore.batch_write_data_to_file() else: filename = ( f"{output_options.output_directory}/compliance/" diff --git a/prowler/compliance/aws/prowler_threatscore_aws.json b/prowler/compliance/aws/prowler_threatscore_aws.json new file mode 100644 index 0000000000..dcc036f7f6 --- /dev/null +++ b/prowler/compliance/aws/prowler_threatscore_aws.json @@ -0,0 +1,1864 @@ +{ + "Framework": "ProwlerThreatScore", + "Version": "1.0", + "Provider": "AWS", + "Description": "Prowler ThreatScore Compliance Framework for AWS ensures that the AWS account is compliant taking into account four main pillars: Identity and Access Management, Attack Surface, Forensic Readiness and Encryption", + "Requirements": [ + { + "Id": "1.1.1", + "Description": "Ensure MFA is enabled for the 'root' user account", + "Checks": [ + "iam_root_mfa_enabled" + ], + "Attributes": [ + { + "Title": "MFA enabled for 'root'", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "The root user account holds the highest level of privileges within an AWS account. Enabling Multi-Factor Authentication (MFA) enhances security by adding an additional layer of protection beyond just a username and password. With MFA activated, users must provide their credentials (username and password) along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.", + "AdditionalInformation": "Enabling MFA enhances console security by requiring the authenticating user to both possess a time-sensitive key-generating device and have knowledge of their credentials.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.1.2", + "Description": "Ensure hardware MFA is enabled for the 'root' user account", + "Checks": [ + "iam_root_hardware_mfa_enabled" + ], + "Attributes": [ + { + "Title": "Hardware MFA enabled for 'root'", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "The root user account in AWS has the highest level of privileges. Multi-Factor Authentication (MFA) enhances security by adding an extra layer of protection beyond a username and password. When MFA is enabled, users must enter their credentials along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.", + "AdditionalInformation": "A hardware MFA has a smaller attack surface compared to a virtual MFA. Unlike a virtual MFA, which relies on a mobile device that may be vulnerable to malware or compromise, a hardware MFA operates independently, reducing exposure to potential security threats.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.1.3", + "Description": "Ensure multi-factor authentication (MFA) is enabled for all IAM users that have console access", + "Checks": [ + "iam_user_mfa_enabled_console_access" + ], + "Attributes": [ + { + "Title": "MFA enabled for IAM console users", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "To enhance security and reduce the risk of unauthorized access, Multi-Factor Authentication (MFA) should be enabled for all IAM users who have access to the AWS Management Console.", + "AdditionalInformation": "Without Multi-Factor Authentication (MFA), a compromised password alone is enough to allow an attacker to access the console, gaining full visibility and control over AWS resources.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.1.4", + "Description": "Ensure IAM password policy requires minimum length of 14 or greater", + "Checks": [ + "iam_password_policy_minimum_length_14" + ], + "Attributes": [ + { + "Title": "IAM password lenght 14 or greater", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "Password policies help enforce password complexity requirements to strengthen account security. In AWS IAM, password policies can be configured to ensure that user passwords meet specific criteria, including a minimum length requirement. It is recommended to enforce a minimum password length of 14 characters to enhance security.", + "AdditionalInformation": "Requiring longer and more complex passwords reduces the risk of compromise from brute force attacks, credential stuffing, and other password-based threats. A 14-character minimum makes it significantly harder for attackers to guess or crack passwords, improving overall account security and resilience.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "1.1.5", + "Description": "Ensure IAM password policy prevents password reuse", + "Checks": [ + "iam_password_policy_reuse_24" + ], + "Attributes": [ + { + "Title": "IAM prevent password reuse", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "IAM password policies can be configured to prevent users from reusing previous passwords. This ensures that users create new, unique passwords instead of cycling through old ones. It is recommended to enforce password history restrictions to enhance security.", + "AdditionalInformation": "Blocking password reuse helps mitigate the risk of credential-based attacks, such as brute force and credential stuffing. It prevents users from reverting to previously compromised passwords, reducing the likelihood of unauthorized access.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "1.1.6", + "Description": "Ensure IAM password policy require at least one number", + "Checks": [ + "iam_password_policy_number" + ], + "Attributes": [ + { + "Title": "IAM password requires one number or more", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "Password policies help enforce password complexity requirements to strengthen account security. In AWS IAM, password policies can be configured to ensure that user passwords meet specific criteria, including using at least number as requirement. It is recommended to enforce the usage of one number to enhance security.", + "AdditionalInformation": "Requiring more complex passwords reduces the risk of compromise from brute force attacks, credential stuffing, and other password-based threats. Using a number at least makes it significantly harder for attackers to guess or crack passwords, improving overall account security and resilience.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "1.1.7", + "Description": "Ensure IAM password policy require at least one symbol", + "Checks": [ + "iam_password_policy_symbol" + ], + "Attributes": [ + { + "Title": "IAM password policy require one symbol or more", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "IAM password policies can be configured to enforce the use of at least one special character (symbol) in user passwords. Special characters (e.g., @, #, $, %) add complexity, making passwords harder to guess or crack. It is recommended to require at least one symbol in IAM passwords to enhance security.", + "AdditionalInformation": "Requiring a symbol in passwords increases entropy, making brute-force and dictionary attacks more difficult. Attackers often rely on common or predictable password patterns, and enforcing special characters helps reduce the effectiveness of such attacks. This policy strengthens overall password security and aligns with industry best practices.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "1.1.8", + "Description": "Ensure IAM password policy require at least one lowercase letter", + "Checks": [ + "iam_password_policy_lowercase" + ], + "Attributes": [ + { + "Title": "IAM password policy require one lowercase or more", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "IAM password policies can be configured to enforce the use of at least one lowercase letter in user passwords. Including lowercase letters increases password complexity, making them more resistant to brute-force and dictionary attacks. It is recommended to require at least one lowercase letter in IAM passwords to strengthen security.", + "AdditionalInformation": "Requiring at least one lowercase letter ensures that passwords are not composed solely of numbers or uppercase letters, which are easier to guess. Attackers often use wordlists and predictable patterns when attempting to crack passwords. By enforcing lowercase letters, password complexity improves, reducing the likelihood of unauthorized access.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "1.1.9", + "Description": "Ensure IAM password policy requires at least one uppercase letter", + "Checks": [ + "iam_password_policy_uppercase" + ], + "Attributes": [ + { + "Title": "IAM password policy require one uppercase or more", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "IAM password policies can be configured to enforce the use of at least one uppercase letter in user passwords. Including uppercase letters increases password complexity, making them more resilient to brute-force and dictionary attacks. It is recommended to require at least one uppercase letter in IAM passwords to enhance security.", + "AdditionalInformation": "Requiring at least one uppercase letter ensures that passwords are not composed solely of lowercase letters or numbers, which are more predictable and easier to crack. Attackers often rely on common word variations in password attacks, and enforcing uppercase letters adds an additional layer of complexity, reducing the risk of unauthorized access.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "1.1.10", + "Description": "Ensure credentials unused for 45 days or more are disabled", + "Checks": [ + "iam_user_accesskey_unused", + "iam_user_console_access_unused" + ], + "Attributes": [ + { + "Title": "IAM credentials unused disabled", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "AWS IAM users can authenticate and access AWS resources using various types of credentials, including passwords and access keys. To minimize security risks, it is recommended to deactivate or remove any credentials that have been unused for 45 days or more.", + "AdditionalInformation": "Disabling or removing inactive credentials reduces the attack surface and prevents unauthorized access through compromised or forgotten credentials. Unused credentials pose a security risk, as attackers may exploit them if they remain active without regular monitoring. Regularly auditing and revoking stale credentials enhances overall account security.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.1.11", + "Description": "Ensure access keys are rotated every 90 days or less", + "Checks": [ + "iam_rotate_access_key_90_days" + ], + "Attributes": [ + { + "Title": "IAM rotate access keys 90 days", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "Access keys consist of an access key ID and a secret access key, which are used to authenticate and sign programmatic requests made to AWS. These keys allow users and applications to interact with AWS services via the AWS Command Line Interface (CLI), AWS SDKs, PowerShell tools, or direct API calls. To maintain security, it is recommended that all access keys be rotated regularly to minimize the risk of unauthorized access.", + "AdditionalInformation": "Regularly rotating access keys reduces the risk of compromised credentials being exploited. If an access key is leaked, cracked, or stolen, rotating it limits the window of opportunity for malicious use. Additionally, rotating keys ensures that inactive or outdated credentials cannot be used for unauthorized access, enhancing overall security and compliance.", + "LevelOfRisk": 2 + } + ] + }, + { + "Id": "1.1.12", + "Description": "Ensure credentials unused for 90 days or greater are disabled", + "Checks": [ + "iam_user_accesskey_unused", + "iam_user_console_access_unused" + ], + "Attributes": [ + { + "Title": "Credentials unused for 90 days disabled", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "AWS IAM credentials, such as passwords and access keys, grant access to AWS resources. Credentials that remain unused for 90 days or more pose a security risk, as they may belong to inactive users or forgotten accounts. It is recommended to disable or remove IAM credentials that have not been used for 90 days to reduce the risk of unauthorized access.", + "AdditionalInformation": "Disabling unused credentials minimizes the attack surface by ensuring that inactive or abandoned accounts cannot be exploited by attackers. Stale credentials may become a target for brute-force attacks, credential stuffing, or insider threats. Regularly auditing and deactivating unused credentials helps maintain a least privilege security model, reducing the likelihood of unauthorized access.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.1.13", + "Description": "Ensure IAM password policy expires passwords within 90 days or less", + "Checks": [ + "iam_password_policy_expires_passwords_within_90_days_or_less" + ], + "Attributes": [ + { + "Title": "IAM password expires within 90 days", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "IAM password policies can be configured to enforce password expiration after a defined period. It is recommended that passwords be set to expire within 90 days or less to ensure users regularly update their credentials. This helps mitigate security risks associated with stale or compromised passwords that remain active for extended periods.", + "AdditionalInformation": "Requiring password expiration within 90 days or less reduces the risk of credential-based attacks, such as brute-force attacks and credential stuffing, by ensuring that old passwords cannot be used indefinitely. If a password has been exposed or compromised without detection, regular expiration limits the window of opportunity for an attacker to exploit it. This policy enforces stronger access control and aligns with industry security best practices.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "1.1.14", + "Description": "Ensure no root account access key exists", + "Checks": [ + "iam_no_root_access_key" + ], + "Attributes": [ + { + "Title": "No root access key", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "The root account in AWS has unrestricted administrative privileges and should be protected with the highest security measures. Access keys provide programmatic access to AWS, but when linked to the root account, they pose a significant security risk. It is recommended that no access keys be associated with the root account, ensuring that all programmatic access is managed through IAM roles and users with least privilege access.", + "AdditionalInformation": "The root account holds the highest level of privileges in an AWS environment. AWS Access Keys enable programmatic access to AWS resources, but when associated with the root account, they pose a significant security risk. It is recommended to remove all access keys linked to the root account to minimize potential attack vectors. Eliminating root access keys reduces the risk of unauthorized access and enforces the use of role-based IAM accounts with least privilege, promoting a more secure and controlled access management approach.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.2.1", + "Description": "Ensure IAM policies are attached only to groups or roles", + "Checks": [ + "iam_policy_attached_only_to_group_or_roles" + ], + "Attributes": [ + { + "Title": "IAM policies attached to group or roles", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "IAM policies define permissions that control access to AWS resources. To ensure scalability, security, and manageability, it is recommended that IAM policies be attached only to groups or roles rather than individual users. By assigning permissions at the group or role level, organizations can apply consistent security policies and avoid permission sprawl.", + "AdditionalInformation": "Attaching policies to groups or roles simplifies access control, reduces security risks, and improves compliance tracking. This approach prevents overprivileged accounts and ensures a structured, scalable IAM policy framework.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.2.2", + "Description": "Ensure IAM users receive permissions only through groups", + "Checks": [ + "iam_policy_attached_only_to_group_or_roles" + ], + "Attributes": [ + { + "Title": "IAM users get permissions through groups", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "IAM users gain access to AWS services, functions, and data through IAM policies. There are four ways to assign policies to a user: 1.Inline (User-Specific) Policy – Editing the policy directly within the user’s profile.2.Directly Attached Policy – Assigning a standalone policy to a user.3.Group-Based Policy (Recommended) – Adding the user to an IAM group with an attached policy. 4.Group with Inline Policy – Assigning an inline policy to a group that includes the user.Among these methods, only the third approach (group-based policies) is recommended for security and manageability.", + "AdditionalInformation": "Managing IAM permissions exclusively through groups ensures consistent, scalable, and role-based access control. This approach reduces the risk of excessive privileges, simplifies auditing, and aligns user permissions with organizational roles.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.3.1", + "Description": "Ensure IAM policies that allow full *:* administrative privileges are not attached", + "Checks": [ + "iam_aws_attached_policy_no_administrative_privileges", + "iam_customer_attached_policy_no_administrative_privileges" + ], + "Attributes": [ + { + "Title": "IAM policies with full privileges not attached", + "Section": "1. IAM", + "SubSection": "1.3 Privilege Escalation Prevention", + "AttributeDescription": "IAM policies define permissions for users, groups, and roles, controlling access to AWS resources. Following the principle of least privilege, users should be granted only the permissions necessary to perform their tasks. Instead of assigning broad administrative privileges, permissions should be carefully crafted to allow only the required actions.", + "AdditionalInformation": "Starting with minimal permissions and granting additional access as needed is significantly more secure than providing excessive permissions and attempting to restrict them later. Assigning full administrative privileges increases the risk of unauthorized or accidental actions that could compromise AWS resources. IAM policies containing Effect: Allow, Action: , Resource: should be removed to prevent unrestricted access and enforce security best practices.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.2.3", + "Description": "Ensure a support role has been created to manage incidents with AWS Support", + "Checks": [ + "iam_support_role_created" + ], + "Attributes": [ + { + "Title": "Support role exists to manage incidents", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "AWS offers a Support Center for incident notification, response, technical support, and customer service assistance. To ensure secure and controlled access, an IAM role should be created with a properly assigned policy, allowing only authorized users to manage incidents with AWS Support.", + "AdditionalInformation": "Implementing least privilege access control ensures that only designated users can interact with AWS Support. Assigning an IAM role with a specific policy limits access to only necessary actions, reducing the risk of unauthorized modifications or exposure of sensitive account information.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.2.4", + "Description": "Ensure IAM instance roles are used for AWS resource access from instances", + "Checks": [ + "ec2_instance_profile_attached" + ], + "Attributes": [ + { + "Title": "Roles used for resource access from instances", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "AWS instances can access AWS resources either by embedding access keys in API calls or by assigning an IAM role with the necessary permissions. Using IAM roles ensures secure, controlled access without hardcoding credentials.", + "AdditionalInformation": "IAM roles eliminate the risks associated with hardcoded credentials, reducing exposure to external threats. Unlike access keys, which can be used outside AWS if compromised, IAM roles require an attacker to maintain control of an instance to exploit privileges. Additionally, IAM roles simplify credential management by ensuring permissions are automatically updated without the need for manual key rotation.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "4.1.3", + "Description": "Ensure that all expired SSL/TLS certificates stored in AWS IAM are removed", + "Checks": [ + "iam_no_expired_server_certificates_stored" + ], + "Attributes": [ + { + "Title": "Expired SSL/TLS certificates removed", + "Section": "4. Encryption", + "SubSection": "4.1 In-Transit", + "AttributeDescription": "To enable HTTPS connections for applications and websites hosted on AWS, an SSL/TLS server certificate is required. AWS provides two options for managing certificates: AWS Certificate Manager (ACM) – The preferred method for managing SSL/TLS certificates, automating renewals and deployment. IAM Certificate Storage – Used only when deploying SSL/TLS certificates in regions not supported by ACM. IAM securely encrypts private keys and stores them, but certificates must be obtained from an external provider. ACM certificates cannot be uploaded to IAM, and IAM certificates cannot be managed from the IAM Console.", + "AdditionalInformation": "Removing expired SSL/TLS certificates prevents the accidental deployment of invalid certificates, which could cause service disruptions, security warnings, and loss of credibility for applications using AWS services like Elastic Load Balancer (ELB). As a best practice, expired certificates should be deleted to maintain a secure and trusted application environment.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.2.5", + "Description": "Avoid the use of the 'root' account", + "Checks": [ + "iam_avoid_root_usage" + ], + "Attributes": [ + { + "Title": "Don't use root account", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "The root account in AWS has unrestricted administrative privileges and should be used only for initial account setup and emergency scenarios. Regular operations should be performed using IAM users or roles with least privilege access to minimize security risks.", + "AdditionalInformation": "Using the root account increases the risk of unauthorized access, accidental misconfigurations, and privilege misuse. By restricting root account usage and delegating tasks to IAM users or roles, organizations can enforce better access control, auditing, and security best practices.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.2.6", + "Description": "Ensure that IAM Access Analyzer is enabled for all regions", + "Checks": [ + "accessanalyzer_enabled" + ], + "Attributes": [ + { + "Title": "Access Analyzer enabled", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "Enable IAM Access Analyzer for all AWS regions to monitor IAM policies and identify resources with unintended external access. IAM Access Analyzer, introduced at AWS re:Invent 2019, scans resource-based policies and provides visibility into which resources—such as KMS keys, IAM roles, S3 buckets, Lambda functions, and SQS queues—are accessible by external accounts or federated users. This allows administrators to enforce least privilege access and mitigate unauthorized access risks. IAM Access Analyzer operates within the same AWS region as the resources being analyzed.", + "AdditionalInformation": "IAM Access Analyzer enhances security visibility by detecting AWS resources shared with external entities, helping organizations identify potential security risks and ensure compliance with least privilege principles. It continuously evaluates resource-based policies using logic-based analysis, allowing teams to promptly remediate misconfigurations that could lead to unauthorized access or data exposure.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.2.7", + "Description": "Ensure IAM users are managed centrally via identity federation or AWS Organizations for multi-account environments", + "Checks": [ + "iam_check_saml_providers_sts" + ], + "Attributes": [ + { + "Title": "IAM users managed centrally or by organizations", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "In multi-account AWS environments, centralizing IAM user management improves control, security, and access management efficiency. Instead of creating separate IAM users in each account, access should be managed through role assumption. This can be achieved using AWS Organizations or federation with an external identity provider (e.g., AWS IAM Identity Center, Okta, or Active Directory).", + "AdditionalInformation": "Centralizing IAM user management into a single identity store simplifies administration, reduces the risk of access misconfigurations, and enforces consistent security policies across all accounts. This approach enhances security, scalability, and compliance while minimizing user duplication and permission errors.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.3.2", + "Description": "Ensure access to AWSCloudShellFullAccess is restricted", + "Checks": [ + "iam_policy_cloudshell_admin_not_attached" + ], + "Attributes": [ + { + "Title": "AWSCloudShellFullAccess restricted", + "Section": "1. IAM", + "SubSection": "1.3 Privilege Escalation Prevention", + "AttributeDescription": "AWS CloudShell provides a managed command-line interface (CLI) for interacting with AWS services. The AWSCloudShellFullAccess IAM policy grants full access to CloudShell, including file upload and download capabilities between a user’s local system and the CloudShell environment. Within CloudShell, users have sudo privileges and unrestricted internet access, making it possible to install software—such as file transfer tools—that could facilitate data movement to external servers.", + "AdditionalInformation": "Access to AWSCloudShellFullAccess should be restricted, as it can serve as a potential data exfiltration vector for malicious or compromised cloud administrators. Granting full permissions to CloudShell increases the risk of unauthorized data transfers outside the AWS environment. AWS provides guidance on creating more restrictive IAM policies to limit file transfer capabilities, reducing security risks.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.3.3", + "Description": "Ensure no IAM Inline policies allow actions that may lead into Privilege Escalation", + "Checks": [ + "iam_inline_policy_allows_privilege_escalation" + ], + "Attributes": [ + { + "Title": "IAM policy allow privilege escalation", + "Section": "1. IAM", + "SubSection": "1.3 Privilege Escalation Prevention", + "AttributeDescription": "IAM inline policies define permissions directly attached to users, groups, or roles, rather than being managed as standalone policies. If improperly configured, these policies can grant actions that enable privilege escalation, allowing users to elevate their access beyond intended permissions. Privilege escalation can occur through misconfigured IAM roles, excessive permissions, or indirect access paths, potentially leading to unauthorized control over AWS resources.", + "AdditionalInformation": "Users with some IAM permissions are allowed to elevate their privileges up to administrator rights.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "4.1.1", + "Description": "Ensure S3 Bucket Policy is set to deny HTTP requests", + "Checks": [ + "s3_bucket_secure_transport_policy" + ], + "Attributes": [ + { + "Title": "S3 bucket deny HTTP requests", + "Section": "4. Encryption", + "SubSection": "4.1 In-Transit", + "AttributeDescription": "Amazon S3 bucket permissions can be configured using a bucket policy to enforce access restrictions. To enhance security, objects within the bucket should be made accessible only via HTTPS, ensuring encrypted data transmission.", + "AdditionalInformation": "By default, Amazon S3 accepts both HTTP and HTTPS requests, which can expose data to interception. To enforce secure access, HTTP requests should be explicitly denied in the bucket policy. Simply allowing HTTPS without blocking HTTP does not fully comply with security best practices, as unencrypted requests may still be accepted.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "4.1.2", + "Description": "Ensure that EC2 Metadata Service only allows IMDSv2", + "Checks": [ + "ec2_instance_imdsv2_enabled" + ], + "Attributes": [ + { + "Title": "EC2 Metadata Service only allows IMDSv2", + "Section": "4. Encryption", + "SubSection": "4.1 In-Transit", + "AttributeDescription": "AWS EC2 instances allow users to choose between Instance Metadata Service Version 1 (IMDSv1), which uses a request/response model, or Instance Metadata Service Version 2 (IMDSv2), which uses a session-based approach for enhanced security", + "AdditionalInformation": "Instance metadata refers to the data about an EC2 instance, such as host names, events, and security groups, that is used for managing and configuring the instance. When enabling the Metadata Service, users can opt for either IMDSv1, which operates via a simple request/response model, or IMDSv2, which implements session authentication for additional security. With IMDSv2, each request is secured by session-based authentication, ensuring that all interactions with the instance's metadata and credentials are protected. IMDSv1, on the other hand, may expose instances to Server-Side Request Forgery (SSRF) attacks. To improve security, Amazon recommends using IMDSv2", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.1", + "Description": "Ensure MFA Delete is enabled on S3 buckets", + "Checks": [ + "s3_bucket_no_mfa_delete" + ], + "Attributes": [ + { + "Title": "MFA delete enabled on S3 buckets", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Enabling MFA Delete on a sensitive or classified Amazon S3 bucket adds an extra layer of protection by requiring two-factor authentication for critical actions, such as deleting object versions or changing the bucket’s versioning state.", + "AdditionalInformation": "MFA Delete helps prevent accidental or malicious deletions by requiring an additional authentication step. This mitigates the risk of data loss due to compromised credentials or unauthorized access, ensuring that critical objects remain protected.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.2", + "Description": "Ensure all data in Amazon S3 has been discovered, classified, and secured when necessary", + "Checks": [ + "macie_is_enabled" + ], + "Attributes": [ + { + "Title": "Macie enabled", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Amazon S3 buckets may store sensitive data that needs to be discovered, classified, monitored, and protected to maintain security and compliance. Amazon Macie, along with third-party tools, can automatically inventory S3 buckets and identify sensitive data at scale.", + "AdditionalInformation": "Using automated data discovery and classification tools, such as Amazon Macie, enhances security by continuously monitoring S3 buckets for sensitive information. Macie leverages machine learning and pattern matching to detect and protect critical data, reducing the risk of data leaks and unauthorized access.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.1.1", + "Description": "Ensure the default security group of every VPC restricts all traffic", + "Checks": [ + "ec2_securitygroup_default_restrict_traffic" + ], + "Attributes": [ + { + "Title": "Default SG of VPC restrict all traffic", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "Each Amazon VPC includes a default security group that initially denies all inbound traffic, allows all outbound traffic, and permits unrestricted communication between instances within the group. If no security group is specified when launching an instance, it is automatically assigned to this default security group. Since security groups control stateful ingress and egress traffic, it is recommended to restrict all inbound and outbound traffic in the default security group.", + "AdditionalInformation": "Restricting all traffic in the default security group enforces least privilege access by ensuring that AWS resources are explicitly assigned to well-defined security groups. This approach reduces unintended exposure, improves network segmentation, and promotes secure resource placement within AWS environments.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "2.1.2", + "Description": "Ensure routing tables for VPC peering are least access", + "Checks": [ + "vpc_peering_routing_tables_with_least_privilege" + ], + "Attributes": [ + { + "Title": "Routing tables for VPC least access", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "After establishing a VPC peering connection, routing tables must be updated to enable communication between the peered VPCs. Routes can be configured with granular specificity, allowing connections to be restricted to a single host or a specific subnet within the peered VPC.", + "AdditionalInformation": "Defining highly specific routes in VPC peering connections enhances security by limiting access to only the necessary resources. This minimizes the potential impact of a security breach, ensuring that resources outside the defined routes remain inaccessible, reducing the risk of lateral movement within the network.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.1.3", + "Description": "Ensure no Network ACLs allow ingress from 0.0.0.0/0 to remote server administration ports", + "Checks": [ + "ec2_networkacl_allow_ingress_any_port", + "ec2_networkacl_allow_ingress_tcp_port_22", + "ec2_networkacl_allow_ingress_tcp_port_3389" + ], + "Attributes": [ + { + "Title": "No Network ACLs allow ingress from 0.0.0.0/0 to remote server administration ports", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "Network Access Control Lists (NACLs) provide stateless filtering of ingress and egress traffic to AWS resources. It is recommended that NACLs do not allow unrestricted inbound access to remote administration ports, such as SSH (port 22) and RDP (port 3389), over TCP (6), UDP (17), or ALL (-1) protocols to prevent unauthorized access.", + "AdditionalInformation": "Exposing remote server administration ports (e.g., SSH on 22 and RDP on 3389) to the public internet increases the attack surface, making resources more vulnerable to brute-force attacks and unauthorized access. Restricting inbound access to these ports helps reduce security risks and limit potential exploitation.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.1.4", + "Description": "Ensure no security groups allow ingress from 0.0.0.0/0 to remote server administration ports", + "Checks": [ + "ec2_securitygroup_allow_ingress_from_internet_to_all_ports", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_22", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_3389" + ], + "Attributes": [ + { + "Title": "No SG allow ingress from 0.0.0.0/0 to remote server administration ports", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "Security groups enforce stateful filtering of ingress and egress traffic to AWS resources. To enhance security, no security group should allow unrestricted inbound access to remote administration ports, such as SSH (port 22) and RDP (port 3389), over TCP (6), UDP (17), or ALL (-1) protocols.", + "AdditionalInformation": "Exposing remote administration ports to the public internet significantly increases the attack surface, making resources more vulnerable to brute-force attacks, exploitation, and unauthorized access. Restricting ingress traffic to these ports helps reduce security risks and prevent potential system compromises.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "2.2.3", + "Description": "Ensure EBS snapshots are not publicly accessible", + "Checks": [ + "ec2_ebs_public_snapshot" + ], + "Attributes": [ + { + "Title": "EBS snapshots nor publicy accessible", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Amazon Elastic Block Store (EBS) snapshots contain backups of EC2 volumes, which may include sensitive data such as credentials, application configurations, or customer information. EBS snapshots should never be publicly accessible to prevent unauthorized access and data exposure. By default, snapshots are private, but they can be manually shared with other AWS accounts or made public, which poses a significant security risk if misconfigured.", + "AdditionalInformation": "Exposing EBS snapshots publicly increases the risk of data breaches, unauthorized access, and compliance violations. Attackers can scan for publicly accessible snapshots and extract sensitive information. To prevent data leaks, snapshots should be restricted to specific AWS accounts or kept private unless explicitly needed for sharing. Implementing proper access controls helps protect critical data and maintain compliance with security best practices.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "4.2.1", + "Description": "Ensure EBS volume encryption is enabled in all regions", + "Checks": [ + "ec2_ebs_volume_encryption" + ], + "Attributes": [ + { + "Title": "EBS volume encryption", + "Section": "4. Encryption", + "SubSection": "4.2 At-Rest", + "AttributeDescription": "Amazon Elastic Compute Cloud (EC2) supports encryption at rest for Elastic Block Store (EBS) volumes, ensuring that stored data remains protected. While EBS encryption is disabled by default, organizations can enforce automatic encryption of newly created volumes to enhance data security and compliance.", + "AdditionalInformation": "Enforcing EBS volume encryption reduces the risk of data exposure, unauthorized access, and compliance violations. If encryption remains intact, even if storage is compromised, data remains unreadable to unauthorized users. Encrypting data at rest ensures that sensitive information is protected against accidental disclosure, insider threats, and external attacks.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "4.2.2", + "Description": "Ensure that encryption-at-rest is enabled for RDS instances", + "Checks": [ + "rds_instance_storage_encrypted" + ], + "Attributes": [ + { + "Title": "RDS instances encryption at rest enabled", + "Section": "4. Encryption", + "SubSection": "4.2 At-Rest", + "AttributeDescription": "Amazon Relational Database Service (RDS) supports encryption at rest using the industry-standard AES-256 encryption algorithm to secure database instances and their associated storage. Once enabled, RDS encryption automatically handles access authentication and decryption, ensuring secure data storage with minimal performance impact.", + "AdditionalInformation": "Databases often contain sensitive and business-critical information, making encryption essential to protect against unauthorized access and data breaches. Enabling RDS encryption ensures that underlying storage, automated backups, read replicas, and snapshots are all encrypted, preventing accidental or malicious data exposure while maintaining compliance with security best practices.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "2.3.1", + "Description": "Ensure SNS topics do not allow global send or subscribe", + "Checks": [ + "sns_topics_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "SNS topics do not allow global send or subscribe", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon Simple Notification Service (SNS) topics enable messaging between AWS services, applications, and users. By default, SNS topics should be restricted to trusted AWS accounts or IAM roles to prevent unauthorized access. Allowing global send (sns:Publish) or subscribe (sns:Subscribe) permissions means any AWS account or unauthenticated entity could send messages or subscribe to the topic, potentially leading to spam, data leaks, or misuse of notifications.", + "AdditionalInformation": "SNS topics with global send or subscribe permissions expose AWS environments to unauthorized message injection, data exfiltration, and Denial-of-Service (DoS) attacks. An attacker could flood an SNS topic with malicious or fraudulent messages, leading to unexpected charges or service disruptions. Restricting access ensures that only authorized AWS accounts, applications, or IAM roles can send and receive messages, reducing security risks and protecting system integrity.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.4", + "Description": "Ensure RDS snapshots are not publicly accessible", + "Checks": [ + "rds_instance_no_public_access" + ], + "Attributes": [ + { + "Title": "RDS snapshots not publicy accessible", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Amazon Relational Database Service (RDS) snapshots store backups of database instances, potentially containing sensitive data such as customer records, credentials, and application configurations. By default, RDS snapshots are private, but they can be shared with other AWS accounts or made public, which can lead to data exposure if misconfigured. To prevent unauthorized access, RDS snapshots should never be publicly accessible unless explicitly required and secured.", + "AdditionalInformation": "Publicly accessible RDS snapshots create a serious security risk, as anyone can copy the snapshot and restore the database, exposing sensitive information. Attackers actively scan for publicly available snapshots to extract credentials, personally identifiable information (PII), or business-critical data. To prevent unauthorized access and data leaks, RDS snapshots should remain private or restricted to trusted AWS accounts following the principle of least privilege.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.2.5", + "Description": "Ensure the S3 bucket CloudTrail logs is not publicly accessible", + "Checks": [ + "cloudtrail_logs_s3_bucket_is_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "S3 bucket CloudTrail logs is not publicly accessible", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "AWS CloudTrail logs record account activity, including API calls, user actions, and resource modifications, making them critical for security monitoring and compliance auditing. These logs are typically stored in an Amazon S3 bucket for long-term retention and analysis. To protect sensitive security data, the S3 bucket storing CloudTrail logs should never be publicly accessible.", + "AdditionalInformation": "If the S3 bucket containing CloudTrail logs is publicly accessible, unauthorized users could access sensitive security information, including API calls, IAM activity, and infrastructure changes. Exposing CloudTrail logs can help attackers reconstruct system activity, identify vulnerabilities, and plan targeted attacks. To prevent data leaks and unauthorized access, CloudTrail log buckets should be restricted using IAM policies, bucket policies, and S3 Block Public Access settings.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.2.6", + "Description": "Ensure Redshift clusters do not have a public endpoint", + "Checks": [ + "redshift_cluster_public_access" + ], + "Attributes": [ + { + "Title": "Redshift clusters dont have a public endpoint", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Amazon Redshift clusters store and process large-scale data for analytics and business intelligence workloads. By default, Redshift clusters can be configured with a public endpoint, making them accessible from the internet. To minimize security risks, Redshift clusters should be restricted to private networks and should not have a public endpoint unless absolutely necessary and properly secured.", + "AdditionalInformation": "Exposing a Redshift cluster to the public internet increases the risk of unauthorized access, data breaches, and cyberattacks. Attackers could attempt brute-force login attempts, exploit misconfigurations, or access sensitive business data. Keeping Redshift clusters within private subnets and restricting access via security groups, VPC settings, and IAM policies ensures that only trusted networks and users can connect, reducing the attack surface and enhancing data security.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.1.5", + "Description": "Ensure ApiGateway endpoint is not public", + "Checks": [ + "apigateway_restapi_public" + ], + "Attributes": [ + { + "Title": "ApiGateway endpoint is public", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "AWS API Gateway allows developers to create, deploy, and manage APIs that connect applications to backend services. By default, API Gateway endpoints can be publicly accessible, meaning they can be invoked from anywhere on the internet. To enhance security, API Gateway endpoints should be restricted to private networks using VPC links, private API settings, or access control mechanisms to ensure that only authorized entities can interact with the API.", + "AdditionalInformation": "Publicly accessible API Gateway endpoints can expose backend services to unauthorized access, data leaks, and potential exploitation. Attackers may attempt brute-force authentication, injection attacks, or abuse API functionality if access is not properly restricted. To reduce the attack surface, API Gateway endpoints should be limited to internal use or protected with authentication, IAM permissions, WAF rules, or private VPC access to ensure only trusted users and systems can invoke the API.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.2", + "Description": "Ensure that amazon EC2 instances launched using Auto Scaling group launch configurations do not have Public IP addresses", + "Checks": [ + "autoscaling_group_launch_configuration_no_public_ip" + ], + "Attributes": [ + { + "Title": "EC2 instances launched using autoscaling group launch configurations do not have Public IP addresses", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon EC2 instances launched via Auto Scaling groups can automatically scale workloads based on demand. By default, instances can be assigned public IP addresses, making them accessible from the internet. To enhance security, EC2 instances in Auto Scaling group launch configurations should not have public IP addresses, ensuring they remain within a private network and are only accessible through secure channels such as bastion hosts or VPN connections.", + "AdditionalInformation": "Assigning public IP addresses to Auto Scaling group instances increases the risk of unauthorized access, brute-force attacks, and potential exploitation. Publicly accessible instances can become targets for malicious actors, leading to data breaches or service disruptions. By restricting public IP addresses, organizations can enforce network segmentation, ensuring that EC2 instances are accessed securely via private networks, VPNs, or load balancers.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.3", + "Description": "Ensure that lambda functions have not resource-based policy set as Public", + "Checks": [ + "awslambda_function_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "Lambda functions have not resource-based policy set as Public", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "AWS Lambda functions allow running code without managing servers. Lambda supports resource-based policies that define who can invoke the function. If a Lambda function’s resource-based policy allows public access, it can be triggered by anyone on the internet, posing a significant security risk. To prevent unauthorized execution, Lambda functions should not be publicly accessible unless explicitly required and properly secured.", + "AdditionalInformation": "Publicly accessible Lambda functions can be abused for unauthorized execution, leading to service disruptions, data exfiltration, or increased AWS costs due to excessive invocations. Attackers could exploit misconfigured functions to perform malicious actions, extract sensitive data, or abuse compute resources. To reduce security risks, Lambda functions should only be accessible to specific IAM roles, AWS services, or trusted accounts, enforcing least privilege access and maintaining secure function execution.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.4", + "Description": "Ensure that Lambda have not public URL Function", + "Checks": [ + "awslambda_function_url_public" + ], + "Attributes": [ + { + "Title": "Lambda have not public URL Function", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "AWS Lambda function URLs provide a built-in HTTPS endpoint that allows functions to be invoked directly via HTTP requests. By default, Lambda function URLs can be publicly accessible, meaning anyone on the internet can invoke the function if proper access controls are not enforced. To minimize security risks, Lambda function URLs should not be publicly accessible unless explicitly required and properly restricted.", + "AdditionalInformation": "Exposing Lambda function URLs to the public internet increases the risk of unauthorized access, API abuse, and potential exploitation. Attackers may invoke functions maliciously, leading to data leaks, unauthorized operations, increased costs, or denial-of-service (DoS) attacks. To enhance security, Lambda function URLs should be restricted to specific IAM roles, AWS services, or trusted clients, ensuring that only authorized users can trigger the function.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.5", + "Description": "Ensure DMS instances are not publicly accessible", + "Checks": [ + "dms_instance_no_public_access" + ], + "Attributes": [ + { + "Title": "DMS instances are not publicly accessible", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "AWS Database Migration Service (DMS) instances facilitate data migration between databases across on-premises and cloud environments. By default, DMS instances can be configured with publicly accessible endpoints, making them reachable from the internet. To enhance security and prevent unauthorized access, DMS instances should not be publicly accessible unless explicitly required and properly secured.", + "AdditionalInformation": "Publicly accessible DMS instances increase the risk of unauthorized access, data interception, and potential exploitation. Attackers could target exposed instances to steal or manipulate sensitive data during migration. Restricting public access ensures data migrations remain secure, limiting access to trusted networks, private VPCs, and authorized IAM roles, thereby reducing the attack surface and ensuring compliance with security best practices.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.2.7", + "Description": "Ensure DocumentDB manual cluster snapshot is not public", + "Checks": [ + "documentdb_cluster_public_snapshot" + ], + "Attributes": [ + { + "Title": "DocumentDB manual cluster snapshot is not public", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "AWS DocumentDB manual cluster snapshots store backups of DocumentDB clusters, containing sensitive database information such as application data, configurations, and credentials. By default, snapshots are private, but they can be manually shared or made public, which poses a significant security risk. To prevent unauthorized access, DocumentDB manual cluster snapshots should never be publicly accessible unless explicitly required and properly secured.", + "AdditionalInformation": "Publicly accessible DocumentDB snapshots expose critical database information, increasing the risk of data breaches, unauthorized access, and compliance violations. Attackers could restore the snapshot in their own AWS account and gain full access to the database content. To protect sensitive data, DocumentDB snapshots should only be shared with specific AWS accounts or remain private, following least privilege principles and AWS security best practices.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.6", + "Description": "Ensure there are no EC2 AMIs set as Public", + "Checks": [ + "ec2_ami_public" + ], + "Attributes": [ + { + "Title": "No EC2 AMIs set as Public", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon EC2 Amazon Machine Images (AMIs) contain pre-configured operating system and application environments that can be used to launch new EC2 instances. By default, AMIs are private, but they can be manually shared or made public, which poses a security risk if sensitive data or proprietary configurations are exposed. To prevent unauthorized access and data leaks, EC2 AMIs should not be set as public unless explicitly required and properly secured.", + "AdditionalInformation": "Publicly accessible EC2 AMIs increase the risk of data exposure, unauthorized access, and compliance violations. Attackers could copy, analyze, or exploit public AMIs to extract sensitive credentials, misconfigurations, or proprietary software. Keeping AMIs private or shared only with specific AWS accounts ensures that only trusted users or teams can access and launch instances from them, reducing security risks and preventing unintended data exposure.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.8", + "Description": "Ensure that public access to EBS snapshots is disabled", + "Checks": [ + "ec2_ebs_snapshot_account_block_public_access" + ], + "Attributes": [ + { + "Title": "Public access to EBS snapshots is disabled", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Amazon Elastic Block Store (EBS) snapshots are backups of EC2 volumes that may contain sensitive data, such as credentials, application configurations, and customer records. By default, EBS snapshots are private, but they can be manually shared or made public, allowing anyone to copy or restore them. To prevent unauthorized access and data exposure, public access to EBS snapshots should always be disabled.", + "AdditionalInformation": "Publicly accessible EBS snapshots pose a significant security risk, as attackers can restore and extract sensitive data if a snapshot is exposed. Misconfigured public snapshots have led to data breaches and compliance violations in the past. To mitigate this risk, EBS snapshots should be kept private or explicitly shared only with trusted AWS accounts, following least privilege principles to protect critical data and maintain security compliance.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.1.6", + "Description": "Ensure that ec2 common ports from instances are not internet-exposed", + "Checks": [ + "ec2_instance_port_cassandra_exposed_to_internet", + "ec2_instance_port_cifs_exposed_to_internet", + "ec2_instance_port_elasticsearch_kibana_exposed_to_internet", + "ec2_instance_port_ftp_exposed_to_internet", + "ec2_instance_port_kafka_exposed_to_internet", + "ec2_instance_port_kerberos_exposed_to_internet", + "ec2_instance_port_ldap_exposed_to_internet", + "ec2_instance_port_memcached_exposed_to_internet", + "ec2_instance_port_mongodb_exposed_to_internet", + "ec2_instance_port_mysql_exposed_to_internet", + "ec2_instance_port_oracle_exposed_to_internet", + "ec2_instance_port_postgresql_exposed_to_internet", + "ec2_instance_port_rdp_exposed_to_internet", + "ec2_instance_port_redis_exposed_to_internet", + "ec2_instance_port_sqlserver_exposed_to_internet", + "ec2_instance_port_ssh_exposed_to_internet", + "ec2_instance_port_telnet_exposed_to_internet" + ], + "Attributes": [ + { + "Title": "Common ports from instances are not exposed", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "Amazon EC2 instances can run various services that communicate over common ports such as 22 (SSH), 3389 (RDP), 80 (HTTP), and 443 (HTTPS) (and more). If these ports are open to the internet, attackers can attempt unauthorized access, brute-force attacks, or exploit known vulnerabilities. To reduce security risks, EC2 instances should be configured so that common ports are not exposed to the public internet, unless explicitly required and properly secured.", + "AdditionalInformation": "Exposing common ports directly to the internet increases the attack surface and risks unauthorized access or system compromise. Attackers frequently scan for open ports to target misconfigured or unpatched services. To enhance security, access to EC2 common ports should be restricted using security groups, network ACLs, and VPC configurations, ensuring that only trusted networks and users can connect.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.1.7", + "Description": "Ensure that ec2 security groups do not allow ingress from internet to common ports", + "Checks": [ + "ec2_securitygroup_allow_ingress_from_internet_to_high_risk_tcp_ports", + "ec2_securitygroup_allow_ingress_from_internet_to_port_mongodb_27017_27018", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_ftp_port_20_21", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_22", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_3389", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_cassandra_7199_9160_8888", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_elasticsearch_kibana_9200_9300_5601", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_kafka_9092", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_memcached_11211", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_mysql_3306", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_oracle_1521_2483", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_postgres_5432", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_redis_6379", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_sql_server_1433_1434", + "ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_telnet_23" + ], + "Attributes": [ + { + "Title": "Common ports from security groups do not allow ingress traffic", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "Amazon EC2 security groups act as virtual firewalls, controlling inbound and outbound traffic to instances. If a security group allows ingress (incoming traffic) from the internet (0.0.0.0/0 or ::/0) to common ports such as 22 (SSH), 3389 (RDP), 80 (HTTP), or 443 (HTTPS) (and more), it creates a significant security risk. To minimize exposure, security groups should be configured to restrict ingress access to these ports to only trusted IP addresses or internal networks.", + "AdditionalInformation": "Allowing unrestricted inbound traffic to common ports increases the risk of brute-force attacks, unauthorized access, and exploitation of vulnerabilities. Attackers actively scan for open ports on public-facing EC2 instances to gain unauthorized control. To reduce security risks, ingress rules should be restricted using least privilege principles, IP whitelisting, VPN access, or bastion hosts, ensuring that only authorized users and networks can connect.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "2.3.7", + "Description": "Ensure there are no ECR repositories set as Public", + "Checks": [ + "ecr_repositories_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "No ECR repositories set as Public", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon Elastic Container Registry (ECR) repositories store and manage container images for deployment in AWS services. By default, ECR repositories are private, but they can be manually configured as public, allowing anyone to pull container images. To prevent unauthorized access and potential security risks, ECR repositories should not be set as public unless explicitly required and properly secured.", + "AdditionalInformation": "Publicly accessible ECR repositories expose container images to unauthorized users, increasing the risk of intellectual property theft, malware injection, or unauthorized use of containerized applications. Attackers could analyze public images for vulnerabilities or use misconfigured images for malicious purposes. To mitigate this risk, ECR repositories should remain private or be explicitly shared with trusted AWS accounts, ensuring secure access and compliance with best practices.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.8", + "Description": "Ensure ECS services do not assign public IPs automatically", + "Checks": [ + "ecs_service_no_assign_public_ip" + ], + "Attributes": [ + { + "Title": "No ECS services assign public IPs automatically", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon Elastic Container Service (ECS) allows running containerized applications on AWS. By default, ECS services can be configured to assign public IP addresses to tasks or services, making them directly accessible from the internet. To enhance security, ECS services should be configured not to automatically assign public IPs, ensuring they remain within a private network and are accessed securely through internal load balancers, VPC peering, or private endpoints.", + "AdditionalInformation": "Automatically assigning public IPs to ECS services exposes them to the internet, increasing the risk of unauthorized access, brute-force attacks, and data breaches. Attackers could target publicly exposed containers, exploit vulnerabilities, or disrupt services. To mitigate these risks, ECS services should be restricted to private subnets and accessed through secure networking configurations, such as AWS PrivateLink, VPNs, or internal ALBs.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.9", + "Description": "Ensure ECS task sets do not automatically assign public IP addresses", + "Checks": [ + "ecs_task_set_no_assign_public_ip" + ], + "Attributes": [ + { + "Title": "No ECS tasks sets assign public IPs autocatically", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon Elastic Container Service (ECS) task sets manage multiple versions of a service during deployments. By default, ECS task sets can be configured to automatically assign public IP addresses, making them directly accessible from the internet. To enhance security, ECS task sets should be restricted to private subnets and should not automatically receive public IP addresses unless explicitly required and properly secured.", + "AdditionalInformation": "Automatically assigning public IPs to ECS task sets increases the risk of unauthorized access, cyberattacks, and data exposure. Publicly exposed tasks can be targeted by attackers, leading to service disruptions or exploitation of vulnerabilities. To mitigate these risks, ECS task sets should be restricted to private networking environments, accessed only through internal load balancers, VPC endpoints, or secure VPN connections, ensuring controlled and secure communication.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.9", + "Description": "Ensure EFS mount targets are not publicly accessible", + "Checks": [ + "efs_mount_target_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "No EFS mount targets are publicly accessible", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Amazon Elastic File System (EFS) provides scalable, shared file storage for AWS services. EFS mount targets allow instances to connect to the file system within a VPC. By default, EFS mount targets can be configured with public accessibility, making them reachable from the internet. To enhance security, EFS mount targets should be restricted to private networks and should not be publicly accessible unless explicitly required and properly secured.", + "AdditionalInformation": "Publicly accessible EFS mount targets expose stored data to unauthorized access, cyberattacks, and data breaches. Attackers could exploit misconfigured security groups or network ACLs to access or modify files. To reduce security risks, EFS mount targets should be restricted to private subnets, with access limited to trusted VPCs, security groups, and IAM roles, ensuring secure file storage and controlled access.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.2.10", + "Description": "Ensure that EFS do not have policies which allow access to any client within the VPC", + "Checks": [ + "efs_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "No EFS have policies which allow access to any client within the VPC", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Amazon Elastic File System (EFS) provides shared storage that can be accessed by multiple EC2 instances and services within a VPC. EFS access is controlled through resource-based policies that define which clients can connect. If an EFS policy allows access to any client within the VPC, it increases the risk of unauthorized access and data exposure. To enhance security, EFS policies should be restricted to specific IAM roles, security groups, or trusted resources instead of granting broad access to all VPC clients.", + "AdditionalInformation": "Allowing any client within a VPC to access an EFS file system increases the risk of data leaks, accidental modifications, or unauthorized access by compromised instances or misconfigured services. To minimize exposure, EFS policies should enforce least privilege access, restricting permissions to specific instances, roles, or users that require access, ensuring secure file storage and controlled data access.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.1.8", + "Description": "Ensure EKS cluster Network Policy is Enabled and Set as Appropriate", + "Checks": [ + "eks_cluster_network_policy_enabled" + ], + "Attributes": [ + { + "Title": "EKS cluster Network Policy is Enabled and Set as Appropriate", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "A Network Policy defines how network traffic is controlled and restricted between workloads within a cloud environment. Enforcing network policies ensures that only authorized communication occurs between services, reducing the risk of unauthorized access and lateral movement. It is recommended to enable Network Policies and configure them appropriately to enforce least privilege access and secure communication between workloads.", + "AdditionalInformation": "Without properly configured Network Policies, workloads may be exposed to unnecessary or unauthorized network traffic, increasing the risk of data leaks, exploitation, or lateral movement by attackers. By enabling and enforcing Network Policies, organizations can limit communication between workloads, ensuring that only approved and necessary network interactions are allowed, minimizing the attack surface and enhancing overall security.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.1.9", + "Description": "Ensure EKS Clusters are not publicly accessible", + "Checks": [ + "eks_cluster_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "EKS Clusters are not publicly accessible", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "Amazon Elastic Kubernetes Service (EKS) clusters manage containerized applications and can be configured with either private or public access. If an EKS cluster is publicly accessible, it means that the Kubernetes API endpoint can be reached from the internet, increasing the risk of unauthorized access and attacks. To enhance security, EKS clusters should be restricted to private networks and accessed only through secure VPNs, VPC peering, or AWS PrivateLink.", + "AdditionalInformation": "Exposing an EKS cluster to the public internet increases the risk of brute-force attacks, credential theft, and unauthorized access to Kubernetes workloads. Attackers could exploit misconfigured RBAC policies or API vulnerabilities to gain control over the cluster. To reduce security risks, EKS clusters should be configured with private endpoints, ensuring that only trusted networks and IAM-authenticated users can manage Kubernetes resources.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.1.10", + "Description": "Ensure EKS Clusters are created with Private Nodes", + "Checks": [ + "eks_cluster_private_nodes_enabled" + ], + "Attributes": [ + { + "Title": "EKS Clusters are created with Private Nodes", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "Amazon Elastic Kubernetes Service (EKS) clusters run workloads on worker nodes, which can be either public or private. If EKS clusters are created with public nodes, these nodes are assigned public IP addresses, making them accessible from the internet, which increases the risk of unauthorized access and potential attacks. To enhance security, EKS clusters should be created with private nodes that operate within private subnets and are only accessible through secured networking configurations such as VPNs, VPC peering, or AWS PrivateLink.", + "AdditionalInformation": "Using public nodes in EKS exposes Kubernetes workloads to the internet, increasing the risk of unauthorized access, lateral movement, and potential exploitation. Attackers can target misconfigured workloads, open services, or unsecured API endpoints. By creating EKS clusters with private nodes, organizations can restrict access, limit exposure to public threats, and enforce network segmentation, ensuring that workloads remain secure and isolated within a private VPC environment.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.11", + "Description": "Ensure Elasticache Cluster is not using a public subnet", + "Checks": [ + "elasticache_cluster_uses_public_subnet" + ], + "Attributes": [ + { + "Title": "Elasticache Cluster is not using a public subnet", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Amazon ElastiCache provides in-memory caching services using Redis and Memcached. By default, ElastiCache clusters can be deployed in either public or private subnets. If an ElastiCache cluster is placed in a public subnet, it becomes accessible from the internet, which significantly increases the risk of unauthorized access and data breaches. To enhance security, ElastiCache clusters should only be deployed in private subnets, ensuring restricted access within a VPC.", + "AdditionalInformation": "Deploying an ElastiCache cluster in a public subnet exposes it to external threats, such as unauthorized access, brute-force attacks, and potential data exfiltration. Attackers could exploit misconfigurations to access cached data or disrupt services. By restricting ElastiCache clusters to private subnets, organizations can limit access to trusted resources, enforce VPC security controls, and reduce the attack surface, ensuring secure and efficient caching operations.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.10", + "Description": "Ensure no Elastic Load Balancers are facing internet", + "Checks": [ + "elbv2_internet_facing" + ], + "Attributes": [ + { + "Title": "No Elastic Load Balancers are facing internet", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon Elastic Load Balancers (ELBs) distribute incoming traffic across multiple targets, such as EC2 instances, containers, and Lambda functions. By default, ELBs can be configured as either internet-facing or internal (private). If an ELB is publicly accessible, it exposes backend services to the internet, increasing the risk of unauthorized access and attacks. To enhance security, ELBs should be restricted to private networks unless explicitly required and properly secured.", + "AdditionalInformation": "Publicly accessible Elastic Load Balancers can serve as entry points for unauthorized traffic, brute-force attacks, and potential data breaches. Attackers may exploit misconfigured security groups, open ports, or exposed application endpoints behind the load balancer. To reduce security risks, ELBs should be configured as internal (private), allowing access only from trusted networks, VPNs, or specific VPCs, ensuring that backend services remain protected and isolated from external threats.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.11", + "Description": "Ensure EMR Account Public Access Block enabled", + "Checks": [ + "emr_cluster_account_public_block_enabled" + ], + "Attributes": [ + { + "Title": "EMR Account Public Access Block enabled", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon Elastic MapReduce (EMR) is a managed big data processing service that can access S3, EC2, and other AWS resources. The EMR Account Public Access Block setting helps prevent public access to EMR resources, such as data stored in S3 buckets. If this setting is not enabled, there is a risk that EMR-related data and configurations could be exposed to the public, leading to unauthorized access or data breaches. To enhance security, the Public Access Block should be enabled for the EMR account.", + "AdditionalInformation": "Allowing public access to EMR resources increases the risk of data leaks, unauthorized access, and compliance violations. Attackers could exploit misconfigured policies or publicly accessible S3 buckets to access sensitive data processed by EMR. Enabling EMR Account Public Access Block ensures that S3 data and other EMR-related resources cannot be accessed publicly, reducing exposure and maintaining strong access controls in AWS.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.12", + "Description": "Ensure EMR cluster is not publicly accessible", + "Checks": [ + "emr_cluster_publicly_accesible" + ], + "Attributes": [ + { + "Title": "EMR cluster is not publicly accessible", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon Elastic MapReduce (EMR) is a managed service for processing big data workloads using Apache Spark, Hadoop, and other frameworks. By default, EMR clusters can be configured with public or private access. If an EMR cluster is publicly accessible, it exposes data processing nodes and services to the internet, increasing the risk of unauthorized access and potential exploitation. To enhance security, EMR clusters should only be deployed in private subnets and restricted to trusted networks.", + "AdditionalInformation": "Publicly accessible EMR clusters increase the risk of data breaches, unauthorized access, and attacks on running workloads. Malicious actors could exploit misconfigured security groups, open ports, or weak authentication settings to compromise the cluster. To reduce exposure, EMR clusters should be placed in private subnets, restricted using VPC security controls, IAM permissions, and firewall rules, ensuring secure data processing and access management.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.3.13", + "Description": "Ensure that your AWS EventBridge event bus is not exposed to everyone", + "Checks": [ + "eventbridge_bus_exposed" + ], + "Attributes": [ + { + "Title": "AWS EventBridge event bus is not exposed to everyone", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "AWS EventBridge is a serverless event bus service that enables communication between AWS services, third-party applications, and custom event sources. By default, EventBridge event buses can be configured to allow events from any AWS account or external source. If an event bus is exposed to everyone, unauthorized entities could send events to your environment, potentially leading to security risks, data injection attacks, or service disruptions. To enhance security, event buses should be restricted to specific AWS accounts, services, or trusted IAM roles.", + "AdditionalInformation": "Allowing unrestricted access to an EventBridge event bus increases the risk of malicious event injection, unauthorized access, and data manipulation. Attackers could flood the event bus with malicious events, leading to unexpected behavior, security breaches, or excessive AWS costs. To reduce exposure, event buses should be secured using IAM policies and resource-based permissions, ensuring that only trusted AWS services and accounts can send or receive events.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.12", + "Description": "Ensure S3 Glacier vaults have not policies which allow access to everyone", + "Checks": [ + "glacier_vaults_policy_public_access" + ], + "Attributes": [ + { + "Title": "S3 Glacier vaults have not policies which allow access to everyone", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Amazon S3 Glacier provides low-cost, long-term storage for archival data. Glacier vaults can be configured with resource-based policies that control access. If a Glacier vault policy allows access to everyone, unauthorized users could retrieve or delete archived data, leading to data exposure or loss. To enhance security, Glacier vault policies should be restricted to specific AWS accounts, IAM roles, or trusted entities, ensuring only authorized users can access or manage archived data.", + "AdditionalInformation": "Allowing public access to S3 Glacier vaults poses a significant security risk, increasing the chance of data breaches, unauthorized deletions, or compliance violations. Attackers could restore and download sensitive archived data if the vault is misconfigured. To prevent unauthorized access, Glacier vaults should have strict access controls, using IAM policies, encryption, and resource-based permissions, ensuring that only trusted users and systems can interact with archived data.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.13", + "Description": "Ensure Glue Data Catalogs are not publicly accessible", + "Checks": [ + "glue_data_catalogs_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "Glue Data Catalogs are not publicly accessible", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "AWS Glue Data Catalog is a centralized metadata repository used to store and manage schema information for data lakes and analytics workflows. By default, Glue Data Catalogs can be configured to allow public access, which poses a significant security risk if sensitive metadata is exposed. To enhance security, Glue Data Catalogs should be restricted to specific AWS accounts, IAM roles, or trusted services, ensuring that only authorized users can access or modify catalog information.", + "AdditionalInformation": "Allowing public access to Glue Data Catalogs increases the risk of unauthorized access, data leaks, and compliance violations. Attackers could gain insights into an organization’s data structure or modify catalog entries, leading to potential data corruption or unauthorized data exposure. To reduce security risks, Glue Data Catalogs should be secured using IAM policies, resource-based permissions, and AWS Lake Formation, ensuring that only trusted accounts and services can interact with metadata.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.3.14", + "Description": "Ensure Kafka Cluster is not exposed to the public", + "Checks": [ + "kafka_cluster_is_public" + ], + "Attributes": [ + { + "Title": "Kafka Cluster is not exposed to the public", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon Managed Streaming for Apache Kafka (MSK) allows organizations to build and manage real-time data streaming applications. If a Kafka cluster is publicly accessible, it exposes data streams, configurations, and messaging topics to the internet, increasing the risk of unauthorized access, data interception, and service disruptions. To enhance security, Kafka clusters should be restricted to private networks, ensuring that only trusted AWS resources, VPCs, and IAM-authenticated users can interact with the service.", + "AdditionalInformation": "Exposing a Kafka cluster to the public internet creates significant security risks, including unauthorized data ingestion, data leaks, and message tampering. Attackers could consume, modify, or inject malicious data into Kafka topics, disrupting real-time analytics and application workflows. To mitigate these risks, Kafka clusters should be deployed in private subnets, with access restricted via VPC security groups, IAM policies, and AWS PrivateLink, ensuring secure and controlled data streaming.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.14", + "Description": "Ensure there are no internet exposed KMS keys", + "Checks": [ + "kms_key_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "No internet exposed KMS keys", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "AWS Key Management Service (KMS) provides secure encryption key management for data encryption and cryptographic operations. If KMS keys are exposed to the internet, unauthorized entities could potentially use, modify, or compromise encryption keys, leading to data breaches and security vulnerabilities. To enhance security, KMS keys should be restricted to trusted AWS accounts, IAM roles, and specific AWS services, ensuring that only authorized users and systems can access and manage them.", + "AdditionalInformation": "Exposing KMS keys to the public poses a critical security risk, as compromised keys can lead to unauthorized data decryption, loss of data integrity, and compliance violations. Attackers could potentially use public KMS keys to encrypt or decrypt sensitive data, undermining security controls. To prevent unauthorized access, KMS key policies should enforce strict access control using IAM permissions, VPC endpoint policies, and AWS PrivateLink, ensuring that encryption operations remain fully secured and isolated from the public internet.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.15", + "Description": "Ensure lightsail database is not in public mode", + "Checks": [ + "lightsail_database_public" + ], + "Attributes": [ + { + "Title": "Lightsail database not public", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "AWS Lightsail Databases provide managed database solutions for applications. If a Lightsail database is set to public mode, it is directly accessible from the internet, increasing the risk of unauthorized access and data breaches. To enhance security, Lightsail databases should be configured in private mode, ensuring they are accessible only from trusted instances, private networks, or VPN connections.", + "AdditionalInformation": "Publicly accessible Lightsail databases expose sensitive data to unauthorized access, brute-force attacks, and potential exploitation. Attackers can attempt to compromise credentials, inject malicious queries, or exfiltrate data. To mitigate these risks, Lightsail databases should remain private, with access controlled through firewalls, IAM authentication, and private networking configurations, ensuring secure database connectivity and data protection.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.16", + "Description": "Ensure that Lightsail instances are not publicly accessible", + "Checks": [ + "lightsail_instance_public" + ], + "Attributes": [ + { + "Title": "Lightsail instances are not publicly accessible", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "AWS Lightsail instances provide a simple way to deploy and manage cloud-based virtual machines. If a Lightsail instance is publicly accessible, it can be directly reached from the internet, increasing the risk of unauthorized access, attacks, and data breaches. To enhance security, Lightsail instances should be restricted to private access, ensuring they are reachable only through secure connections, such as VPNs, bastion hosts, or private networking configurations.", + "AdditionalInformation": "Publicly exposed Lightsail instances create a larger attack surface, making them vulnerable to brute-force attacks, unauthorized access, and exploitation of software vulnerabilities. Attackers could compromise credentials, gain control over the instance, or disrupt services. To mitigate these risks, Lightsail instances should be secured using firewalls, private IP configurations, security group restrictions, and IAM-based access controls, ensuring that only trusted users and networks can connect.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.3.17", + "Description": "Ensure MQ brokers are not publicly accessible", + "Checks": [ + "mq_broker_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "MQ brokers not publicly accessible", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "AWS MQ brokers manage message queues for applications, facilitating secure and reliable communication between distributed services. If an MQ broker is publicly accessible, it can be reached from the internet, increasing the risk of unauthorized access, message interception, and data breaches. To enhance security, MQ brokers should be restricted to private networks, ensuring they are accessible only from trusted VPCs, private endpoints, or secure VPN connections.", + "AdditionalInformation": "Publicly exposed MQ brokers pose a significant security risk, as attackers can attempt to intercept messages, inject malicious data, or disrupt message delivery. This could lead to data manipulation, unauthorized access to sensitive information, and system-wide outages. To mitigate these risks, MQ brokers should be configured within private subnets, with access restricted using security groups, IAM policies, and VPC endpoint controls, ensuring secure and controlled message queue operations.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.3.18", + "Description": "Ensure NeptuneDB manual cluster snapshot is not public", + "Checks": [ + "neptune_cluster_public_snapshot" + ], + "Attributes": [ + { + "Title": "NeptuneDB manual cluster snapshot is not public", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon NeptuneDB manual cluster snapshots store backups of graph database clusters, containing sensitive data such as relationships, metadata, and application configurations. By default, NeptuneDB snapshots are private, but they can be manually shared or made public, which can expose critical database information. To enhance security, NeptuneDB manual snapshots should never be publicly accessible, ensuring they are only shared with trusted AWS accounts when necessary.", + "AdditionalInformation": "Publicly accessible NeptuneDB snapshots pose a significant security risk, as attackers could restore the snapshot in their own AWS account and gain full access to the database contents. This could lead to data leaks, compliance violations, and unauthorized access to sensitive business information. To prevent data exposure, NeptuneDB snapshots should be restricted using IAM policies and AWS resource-based permissions, ensuring that only authorized users and services can access and manage database backups securely.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.19", + "Description": "Ensure Neptune Cluster is not using a public subnet", + "Checks": [ + "neptune_cluster_uses_public_subnet" + ], + "Attributes": [ + { + "Title": "Neptune Cluster is not using a public subnet", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon Neptune clusters provide a fully managed graph database service designed for applications requiring complex relationship queries. By default, Neptune clusters can be deployed in either public or private subnets. If a Neptune cluster is placed in a public subnet, it becomes accessible from the internet, significantly increasing the risk of unauthorized access and data breaches. To enhance security, Neptune clusters should only be deployed in private subnets, ensuring access is restricted to trusted VPCs, IAM roles, and security group configurations.", + "AdditionalInformation": "Deploying a Neptune cluster in a public subnet exposes the database endpoints to external threats, making them vulnerable to brute-force attacks, unauthorized queries, and data exfiltration. Attackers could exploit misconfigurations to gain access to sensitive graph data, leading to potential compliance violations and security incidents. To reduce exposure, Neptune clusters should be restricted to private subnets, with access controlled through VPC security groups, IAM authentication, and private endpoint configurations, ensuring secure database operations and protected data access.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.20", + "Description": "Ensure Amazon Opensearch/Elasticsearch domains are not publicly accessible", + "Checks": [ + "opensearch_service_domains_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "Amazon Opensearch/Elasticsearch domains are not publicly accessible", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon OpenSearch (formerly Elasticsearch) domains provide search, analytics, and log management capabilities for applications. If an OpenSearch/Elasticsearch domain is publicly accessible, it can be reached from the internet, exposing sensitive data and administrative controls to unauthorized users. To enhance security, OpenSearch domains should be restricted to private networks, ensuring access is limited to trusted VPCs, IAM roles, or specific security group rules.", + "AdditionalInformation": "Publicly accessible OpenSearch/Elasticsearch domains pose a significant security risk, as attackers could execute unauthorized queries, modify data, or gain administrative control over the cluster. This could lead to data breaches, service disruptions, and compliance violations. To mitigate these risks, OpenSearch domains should be deployed in private subnets, with access controlled using VPC restrictions, fine-grained access control (FGAC), IAM policies, and security group rules, ensuring secure and isolated search and analytics operations.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.2.15", + "Description": "Ensure that S3 buckets have not policies which allow WRITE access", + "Checks": [ + "s3_bucket_policy_public_write_access" + ], + "Attributes": [ + { + "Title": "S3 buckets have not policies which allow WRITE access", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Amazon S3 buckets store and manage data, files, and application assets. Bucket policies control access permissions, and if an S3 bucket has a policy that allows WRITE access to everyone, unauthorized users can upload, modify, or delete objects, leading to data tampering, security breaches, or service disruptions. To enhance security, S3 bucket policies should be restricted to specific AWS accounts, IAM roles, or trusted services, ensuring only authorized users have WRITE permissions.", + "AdditionalInformation": "Allowing unrestricted WRITE access to an S3 bucket increases the risk of unauthorized modifications, data injection attacks, and accidental data loss. Attackers could upload malicious files, delete critical data, or overwrite important configurations. To prevent unauthorized changes, S3 bucket policies should explicitly deny public WRITE access, enforce least privilege access control, and use AWS Block Public Access settings to ensure secure and controlled data storage.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.16", + "Description": "Ensure there are no S3 buckets listable by Everyone or Any AWS customer", + "Checks": [ + "s3_bucket_public_list_acl" + ], + "Attributes": [ + { + "Title": "No S3 buckets are listable by Everyone or Any AWS customer", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Amazon S3 buckets store sensitive data and should have restricted access permissions. If an S3 bucket is listable by Everyone or Any AWS customer, unauthorized users can enumerate the objects within the bucket, potentially exposing sensitive information such as filenames, metadata, or even public datasets. To enhance security, S3 bucket permissions should be configured to restrict LIST access to only authorized IAM roles, AWS accounts, or specific services.", + "AdditionalInformation": "Allowing public or AWS-wide LIST access increases the risk of data enumeration, unauthorized access, and information leaks. Attackers or unauthorized users could identify and analyze stored files, extract metadata, or infer sensitive data. To mitigate this risk, S3 bucket policies should explicitly deny public LIST access, enforce least privilege permissions, and use AWS Block Public Access settings to prevent unintended data exposure.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.17", + "Description": "Ensure there are no S3 buckets writable by Everyone or Any AWS customer", + "Checks": [ + "s3_bucket_public_write_acl" + ], + "Attributes": [ + { + "Title": "No S3 buckets writable by Everyone or Any AWS customer", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Amazon S3 buckets should have strict access controls to prevent unauthorized modifications. If an S3 bucket is writable by Everyone or Any AWS customer, it allows unauthorized users to upload, modify, or delete objects, leading to data corruption, security breaches, and compliance risks. To enhance security, S3 bucket permissions should be restricted to trusted IAM roles, AWS accounts, or specific services.", + "AdditionalInformation": "Allowing public or AWS-wide WRITE access creates a significant security risk, as attackers can inject malicious files, overwrite critical data, or delete essential objects. This could lead to data loss, malware distribution, or unauthorized system modifications. To prevent unauthorized changes, S3 bucket policies should explicitly deny public WRITE access, enforce least privilege access, and use AWS Block Public Access settings to secure data integrity and prevent unauthorized modifications.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.21", + "Description": "Ensure Amazon SageMaker Notebook instances have not direct internet access", + "Checks": [ + "sagemaker_notebook_instance_without_direct_internet_access_configured" + ], + "Attributes": [ + { + "Title": "Amazon SageMaker Notebook instances have not direct internet access", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon SageMaker Notebook instances provide an interactive environment for machine learning development and data analysis. By default, these instances can be configured with direct internet access, which increases the risk of unauthorized access, data leaks, and exposure to malicious external threats. To enhance security, SageMaker Notebook instances should be restricted to private networks, ensuring they are accessed only through secure VPC connections, IAM authentication, or VPNs.", + "AdditionalInformation": "Allowing direct internet access to SageMaker Notebook instances poses a significant security risk, as attackers could exploit misconfigurations, exfiltrate data, or inject malicious code. Publicly accessible notebooks can lead to data breaches, intellectual property theft, or compromised model training workflows. To mitigate these risks, SageMaker Notebook instances should be configured within private subnets, with internet access disabled, and restricted using security groups, IAM policies, and VPC endpoint configurations to ensure secure and controlled machine learning operations.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.18", + "Description": "Ensure Secrets Manager secrets are not publicly accessible", + "Checks": [ + "secretsmanager_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "Secrets Manager secrets are not publicly accessible", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "AWS Secrets Manager is used to securely store and manage sensitive information, such as API keys, database credentials, and encryption keys. By default, Secrets Manager secrets should be restricted to authorized IAM roles and AWS services. If a secret is publicly accessible, it can be exposed to unauthorized users, leading to data leaks, security breaches, and potential exploitation of sensitive credentials. To enhance security, Secrets Manager secrets should be strictly controlled using IAM policies and resource-based permissions.", + "AdditionalInformation": "Allowing public access to Secrets Manager secrets creates a critical security vulnerability, as attackers could retrieve, misuse, or exfiltrate sensitive information. Compromised secrets could lead to unauthorized access to databases, applications, or cloud services, resulting in data breaches, financial loss, or compliance violations. To mitigate this risk, Secrets Manager secrets should be restricted using least privilege IAM permissions, encrypted with AWS KMS, and accessed only by trusted AWS services and roles, ensuring secure and controlled secret management.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.3.22", + "Description": "Ensure that SES identities are not publicly accessible", + "Checks": [ + "ses_identity_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "SES identities are not publicly accessible", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon Simple Email Service (SES) identities (such as email addresses or domains) are used to send and receive emails through AWS. By default, SES identities should be restricted to authorized AWS accounts and IAM roles. If an SES identity is publicly accessible, unauthorized users could send emails using the identity, leading to email spoofing, phishing attacks, or misuse of the domain for malicious purposes. To enhance security, SES identities should be properly restricted using IAM policies and verified senders.", + "AdditionalInformation": "Allowing public access to SES identities creates a security and reputational risk, as attackers could impersonate the identity, send spam, or launch phishing campaigns. This could lead to domain blacklisting, compliance violations, and damage to the organization’s email reputation. To mitigate these risks, SES identities should be restricted to trusted AWS accounts and IAM roles, ensuring that only authorized services and users can send emails, protecting the integrity and security of email communications.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.3.23", + "Description": "Ensure SQS queues have not policy set as Public", + "Checks": [ + "sqs_queues_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "SQS queues have not policy set as Public", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Amazon Simple Queue Service (SQS) queues enable asynchronous message processing between distributed systems. By default, SQS queues should be restricted to authorized AWS accounts and IAM roles. If an SQS queue has a public policy, it allows anyone on the internet to send, receive, or delete messages, leading to data leaks, unauthorized message injection, and potential denial-of-service (DoS) attacks. To enhance security, SQS queue policies should be configured to allow access only to trusted AWS accounts, IAM roles, or specific AWS services.", + "AdditionalInformation": "Publicly accessible SQS queues pose a significant security risk, as attackers could inject malicious messages, disrupt processing workflows, or delete critical messages, leading to system failures and data integrity issues. To prevent unauthorized access, SQS policies should explicitly deny public access, enforce least privilege access control, and use IAM policies and VPC endpoint restrictions to ensure secure and controlled messaging operations.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.3.24", + "Description": "Ensure that there are not SSM Documents set as public", + "Checks": [ + "ssm_documents_set_as_public" + ], + "Attributes": [ + { + "Title": "No SSM Documents are set as public", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "AWS Systems Manager (SSM) Documents define configuration, automation, and maintenance tasks for AWS resources. By default, SSM documents should be restricted to specific AWS accounts, IAM roles, or AWS services. If an SSM document is set as public, unauthorized users could access, modify, or execute automation tasks on AWS infrastructure, leading to misconfigurations, security breaches, or unintended system modifications. To enhance security, SSM documents should be kept private and assigned only to trusted AWS entities.", + "AdditionalInformation": "Publicly accessible SSM documents pose a significant security risk, as attackers could execute malicious commands, modify system configurations, or disrupt AWS operations. This could lead to unauthorized access, data leaks, compliance violations, or system downtime. To prevent security threats, SSM documents should explicitly deny public access, enforce least privilege permissions, and use IAM policies and resource-based access controls to ensure only trusted users and systems can manage AWS resources.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.1.1", + "Description": "Ensure CloudTrail is enabled in all regions", + "Checks": [ + "cloudtrail_multi_region_enabled" + ], + "Attributes": [ + { + "Title": "CloudTrail enabled", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "AWS CloudTrail is a service that records and monitors AWS API calls across an account, providing detailed logs of who performed what action, when, and from where. CloudTrail captures API activity from the AWS Management Console, SDKs, CLI, and AWS services such as CloudFormation. The logs include key details such as the identity of the API caller, timestamp, source IP address, request parameters, and response elements.", + "AdditionalInformation": "CloudTrail enhances security, auditing, and compliance by providing a complete history of API activities in an AWS account. Enabling a multi-region trail ensures: Detection of unauthorized activity in rarely used AWS regions. Global Service Logging is automatically enabled, capturing API calls from global services such as IAM and AWS Organizations. Tracking of all management events, ensuring that both read and write operations across AWS resources are recorded for improved security monitoring and compliance.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.1.2", + "Description": "Ensure CloudTrail log file validation is enabled", + "Checks": [ + "cloudtrail_log_file_validation_enabled" + ], + "Attributes": [ + { + "Title": "CloudTrail file validation enabled", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "AWS CloudTrail log file validation generates digitally signed digest files containing cryptographic hashes of each log file stored in Amazon S3. These digest files allow users to verify whether logs have been altered, deleted, or remain unchanged after being delivered by CloudTrail. Enabling log file validation ensures data integrity and auditability for security and compliance purposes.", + "AdditionalInformation": "Enabling log file validation enhances security by ensuring the integrity of CloudTrail logs, preventing tampering or unauthorized modifications. This helps: Detect log file alterations, ensuring logs remain trustworthy for audits and investigations. Improve compliance with frameworks that require log integrity, such as PCI DSS, SOC 2, and ISO 27001. Strengthen forensic capabilities, allowing security teams to verify log authenticity in case of a security incident.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.1", + "Description": "Ensure AWS Config is enabled in all regions", + "Checks": [ + "config_recorder_all_regions_enabled" + ], + "Attributes": [ + { + "Title": "AWS Config is enabled", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "AWS Config is a service that continuously monitors, records, and evaluates configuration changes in AWS resources within an account. It tracks configuration items, relationships between resources, and changes over time, delivering logs for security analysis, change management, and compliance auditing. To ensure comprehensive monitoring, AWS Config should be enabled in all regions.", + "AdditionalInformation": "Enabling AWS Config in all regions improves security, visibility, and compliance by: Tracking resource changes, allowing for quick identification of misconfigurations. Supporting security audits and forensic investigations by maintaining a historical record of configurations.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.1.3", + "Description": "Ensure that server access logging is enabled on the CloudTrail S3 bucket", + "Checks": [ + "cloudtrail_logs_s3_bucket_access_logging_enabled" + ], + "Attributes": [ + { + "Title": "Server access logging is enabled on the CloudTrail S3 bucket", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "Server access logging provides detailed records of requests made to an S3 bucket, including request type, accessed resources, timestamp, and requester details. Enabling server access logging on the CloudTrail S3 bucket ensures that all interactions with CloudTrail logs are recorded, improving security visibility and auditability", + "AdditionalInformation": "Enabling server access logging on CloudTrail S3 buckets enhances security monitoring, incident response, and compliance by: Capturing all events affecting CloudTrail logs, helping detect unauthorized access or modifications. Providing an audit trail for forensic investigations and compliance reporting. Enhancing security workflows by storing access logs in a separate, dedicated logging bucket for improved log integrity and analysis.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "4.2.3", + "Description": "Ensure CloudTrail logs are encrypted at rest using KMS CMKs", + "Checks": [ + "cloudtrail_kms_encryption_enabled" + ], + "Attributes": [ + { + "Title": "CloudTrail logs are encrypted at rest using KMS CMKs", + "Section": "4. Encryption", + "SubSection": "4.2 At-Rest", + "AttributeDescription": "AWS CloudTrail records API activity across an AWS account, and its logs contain sensitive security and operational data. AWS Key Management Service (KMS) provides encryption key management using customer-managed keys (CMKs) and Hardware Security Modules (HSMs) to ensure secure key storage and usage. CloudTrail logs can be encrypted using Server-Side Encryption (SSE) with KMS (SSE-KMS) to add an extra layer of protection and access control", + "AdditionalInformation": "Using SSE-KMS encryption for CloudTrail logs enhances security by adding an extra layer of access control. This ensures that only authorized users with both S3 read permissions and KMS decryption rights can access log data, protecting sensitive security information from unauthorized access or tampering. It also helps maintain compliance with security and regulatory standards by enforcing strict encryption controls.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.2.1", + "Description": "Ensure rotation for customer-created symmetric CMKs is enabled", + "Checks": [ + "kms_cmk_rotation_enabled" + ], + "Attributes": [ + { + "Title": "Rotation for customer-created symmetric CMKs enabled", + "Section": "3. Logging and Monitoring", + "SubSection": "3.2 Retention", + "AttributeDescription": "AWS Key Management Service (KMS) allows users to manage encryption keys securely. Key rotation enables the automatic replacement of the backing key (the cryptographic material tied to a customer-managed key (CMK)), ensuring continuous security without disrupting access to previously encrypted data. AWS automatically retains previous backing keys to allow seamless decryption of older data while using a newly generated key for encryption. It is recommended to enable key rotation for symmetric CMKs, as asymmetric keys do not support this feature.", + "AdditionalInformation": "Regularly rotating encryption keys minimizes the risk associated with key compromise by ensuring that newly encrypted data is protected with a fresh key, reducing the potential impact of an exposed key. Since AWS KMS retains prior backing keys for seamless decryption, rotation does not disrupt access to previously encrypted data. Implementing key rotation enhances security by limiting the exposure window of any single encryption key and aligning with best practices for cryptographic hygiene.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.1.4", + "Description": "Ensure VPC flow logging is enabled in all VPCs", + "Checks": [ + "vpc_flow_logs_enabled" + ], + "Attributes": [ + { + "Title": "VPC flow logging enabled in all VPCs", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "VPC Flow Logs capture and record IP traffic information for network interfaces within a VPC, allowing administrators to monitor and analyze network activity. These logs are stored in Amazon CloudWatch Logs for retrieval and analysis. It is recommended to enable VPC Flow Logs for rejected packets to track unauthorized access attempts, misconfigurations, or potential security threats within the VPC.", + "AdditionalInformation": "Enabling VPC Flow Logs for rejected traffic enhances network visibility and security monitoring by detecting suspicious activity, failed connection attempts, and potential threats. These logs help identify anomalous traffic patterns, troubleshoot connectivity issues, and support incident response workflows, improving overall security posture.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.1.5", + "Description": "Ensure that object-level logging for write events is enabled for S3 buckets", + "Checks": [ + "cloudtrail_s3_dataevents_write_enabled" + ], + "Attributes": [ + { + "Title": "Object-level logging for write events is enabled for S3 buckets", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "S3 object-level API operations, such as GetObject, PutObject, and DeleteObject, are classified as data events in AWS CloudTrail. By default, CloudTrail does not log data events, meaning detailed tracking of individual object interactions is not enabled. To enhance visibility and security, it is recommended to enable object-level logging for S3 buckets to monitor access and modification activities.", + "AdditionalInformation": "Enabling object-level logging helps organizations meet compliance requirements, enhance security monitoring, and detect unauthorized access. It allows administrators to analyze user behavior, track modifications to critical data, and respond to security incidents in real time using Amazon CloudWatch Events, ensuring greater control over S3 bucket activity.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.1.6", + "Description": "Ensure that object-level logging for read events is enabled for S3 buckets", + "Checks": [ + "cloudtrail_s3_dataevents_read_enabled" + ], + "Attributes": [ + { + "Title": "Object-level logging for read events is enabled for S3 buckets", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "S3 object-level API operations, such as GetObject, PutObject, and DeleteObject, are classified as data events in AWS CloudTrail. By default, CloudTrail does not log data events, meaning individual object interactions are not tracked unless explicitly enabled. To improve security monitoring and compliance, it is recommended to enable object-level logging for S3 buckets.", + "AdditionalInformation": "Object-level logging enhances data security, compliance, and operational visibility by providing detailed tracking of who accessed, modified, or deleted objects within S3 buckets. This enables organizations to monitor user behavior, detect unauthorized access, and quickly respond to potential security incidents using Amazon CloudWatch Events.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.2", + "Description": "Ensure unauthorized API calls are monitored", + "Checks": [ + "cloudwatch_log_metric_filter_unauthorized_api_calls" + ], + "Attributes": [ + { + "Title": "Unauthorized API calls are monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of API calls can be achieved by forwarding CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. By configuring metric filters and alarms, organizations can automatically detect and respond to unauthorized API calls, improving security visibility. It is recommended to establish a metric filter and alarm for unauthorized API calls to enhance threat detection and incident response.", + "AdditionalInformation": "Monitoring unauthorized API calls helps identify potential security incidents faster, reducing the time attackers have to exploit vulnerabilities. CloudWatch provides real-time monitoring and alerting, while SIEM solutions offer centralized security event analysis. Detecting unauthorized API calls early allows organizations to take immediate action, investigate potential threats, and strengthen overall AWS security posture.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.3", + "Description": "Ensure management console sign-in without MFA is monitored", + "Checks": [ + "cloudwatch_log_metric_filter_sign_in_without_mfa" + ], + "Attributes": [ + { + "Title": "Management console sign-in without MFA is monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be implemented by directing CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. By setting up metric filters and alarms, organizations can detect and respond to security risks effectively. It is recommended to establish a metric filter and alarm for AWS console logins that are not protected by multi-factor authentication (MFA) to enhance security monitoring.", + "AdditionalInformation": "Monitoring console logins without MFA improves visibility into accounts that lack strong authentication controls. Accounts without MFA are more vulnerable to credential theft, brute-force attacks, and unauthorized access. By detecting these login attempts in real-time, organizations can identify security gaps, enforce MFA policies, and reduce the risk of account compromise.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.4", + "Description": "Ensure usage of the root account is monitored", + "Checks": [ + "cloudwatch_log_metric_filter_root_usage" + ], + "Attributes": [ + { + "Title": "Usage of root account monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be achieved by directing CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. Setting up metric filters and alarms helps detect potential security threats. It is recommended to establish a metric filter and alarm for root account login attempts to identify unauthorized access or improper use of the highly privileged root account.", + "AdditionalInformation": "Monitoring root account logins enhances visibility into the usage of the most privileged AWS account, which should be used only in exceptional cases. Frequent or unauthorized root logins increase security risks by exposing critical administrative controls. Detecting root login attempts in real time enables organizations to identify potential security incidents, enforce least privilege principles, and limit unnecessary use of the root account.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.3.5", + "Description": "Ensure IAM policy changes are monitored", + "Checks": [ + "cloudwatch_log_metric_filter_policy_changes" + ], + "Attributes": [ + { + "Title": "IAM policy changes are monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be implemented by directing CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. By configuring metric filters and alarms, organizations can detect critical security events. It is recommended to establish a metric filter and alarm for changes to Identity and Access Management (IAM) policies to track modifications that could affect authentication and authorization controls.", + "AdditionalInformation": "Monitoring IAM policy changes helps ensure that access controls remain secure and intact. Unauthorized or unintended modifications to IAM policies can lead to privilege escalation, misconfigurations, and security breaches. Detecting these changes in real-time allows organizations to respond quickly to potential threats, enforce least privilege principles, and maintain a strong security posture.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.6", + "Description": "Ensure CloudTrail configuration changes are monitored", + "Checks": [ + "cloudwatch_log_metric_filter_and_alarm_for_cloudtrail_configuration_changes_enabled" + ], + "Attributes": [ + { + "Title": "CloudTrail configuration changes are monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be implemented by directing CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. By configuring metric filters and alarms, organizations can track critical security events. It is recommended to establish a metric filter and alarm to detect changes to CloudTrail configurations, ensuring that logging remains active and tamper-proof.", + "AdditionalInformation": "Monitoring CloudTrail configuration changes helps maintain continuous visibility into AWS account activity. Unauthorized modifications to CloudTrail settings could disable or alter logging, potentially allowing malicious activity to go undetected. Detecting these changes in real time enables organizations to quickly respond to threats, enforce security best practices, and ensure compliance with auditing requirements.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.7", + "Description": "Ensure AWS Management Console authentication failures are monitored", + "Checks": [ + "cloudwatch_log_metric_filter_authentication_failures" + ], + "Attributes": [ + { + "Title": "AWS Management Console authentication failures are monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be implemented by directing CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. By setting up metric filters and alarms, organizations can detect potential security threats. It is recommended to establish a metric filter and alarm for failed console authentication attempts to identify potential unauthorized access attempts or brute-force attacks.", + "AdditionalInformation": "Monitoring failed console logins helps detect brute-force attempts and unauthorized access attempts early. Repeated failed authentication attempts can indicate malicious activity, and tracking them allows security teams to identify suspicious IP addresses, correlate with other security events, and take proactive measures to protect AWS accounts.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.8", + "Description": "Ensure disabling or scheduled deletion of customer created CMKs is monitored", + "Checks": [ + "cloudwatch_log_metric_filter_disable_or_scheduled_deletion_of_kms_cmk" + ], + "Attributes": [ + { + "Title": "Disabling or scheduled deletion of customer created CMKs is monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be achieved by forwarding CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. By configuring metric filters and alarms, organizations can detect security-critical changes. It is recommended to set up a metric filter and alarm for customer-managed KMS keys (CMKs) that are disabled or scheduled for deletion to prevent unintended encryption key loss.", + "AdditionalInformation": "Disabling or deleting a customer-managed CMK can render encrypted data permanently inaccessible, leading to data loss and service disruptions. Monitoring CMK state changes helps detect unauthorized or accidental modifications, ensuring encryption keys remain available and aligned with security policies. Detecting such changes in real time allows organizations to prevent data loss, maintain compliance, and take corrective action if needed.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.9", + "Description": "Ensure S3 bucket policy changes are monitored", + "Checks": [ + "cloudwatch_log_metric_filter_for_s3_bucket_policy_changes" + ], + "Attributes": [ + { + "Title": "S3 bucket policy changes are monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be implemented by forwarding CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. By configuring metric filters and alarms, organizations can track critical security-related changes. It is recommended to set up a metric filter and alarm for modifications to S3 bucket policies to detect potential misconfigurations or unauthorized access changes.", + "AdditionalInformation": "Monitoring S3 bucket policy changes helps detect and respond to overly permissive configurations that could expose sensitive data. Unauthorized or accidental modifications may grant public access or excessive permissions, increasing the risk of data breaches and compliance violations. Real-time alerts allow security teams to quickly identify, investigate, and correct risky policy changes, reducing exposure and strengthening data security.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.10", + "Description": "Ensure AWS Config configuration changes are monitored", + "Checks": [ + "cloudwatch_log_metric_filter_and_alarm_for_aws_config_configuration_changes_enabled" + ], + "Attributes": [ + { + "Title": "AWS Config configuration changes are monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be implemented by directing CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. By configuring metric filters and alarms, organizations can detect critical configuration changes. It is recommended to establish a metric filter and alarm for modifications to AWS Config’s configurations to ensure continuous monitoring and compliance.", + "AdditionalInformation": "Monitoring AWS Config configuration changes helps maintain visibility and control over resource configurations. Unauthorized or accidental modifications to AWS Config settings may result in gaps in security monitoring, misconfigurations going undetected, and compliance violations. Real-time alerts allow security teams to quickly detect, investigate, and respond to changes, ensuring the integrity of configuration tracking across the AWS environment.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.11", + "Description": "Ensure security group changes are monitored", + "Checks": [ + "cloudwatch_log_metric_filter_security_group_changes" + ], + "Attributes": [ + { + "Title": "Security group changes are monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be implemented by forwarding CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. Security groups act as stateful packet filters that control inbound and outbound traffic within a VPC. It is recommended to establish a metric filter and alarm to detect changes to security groups to prevent unauthorized modifications that could expose resources to security threats.", + "AdditionalInformation": "Monitoring security group changes helps ensure that network access controls remain secure and that AWS resources are not unintentionally exposed. Unauthorized or accidental modifications to security groups can create security gaps, increasing the risk of data breaches and unauthorized access. Real-time alerts enable security teams to detect, investigate, and respond to security group changes quickly, maintaining a strong network security posture.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.12", + "Description": "Ensure Network Access Control List (NACL) changes are monitored", + "Checks": [ + "cloudwatch_changes_to_network_acls_alarm_configured" + ], + "Attributes": [ + { + "Title": "Network Access Control List (NACL) changes are monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be implemented by forwarding CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. Network Access Control Lists (NACLs) act as stateless packet filters that control inbound and outbound traffic for subnets within a VPC. It is recommended to establish a metric filter and alarm to detect changes to NACLs to prevent unauthorized modifications that could compromise network security.", + "AdditionalInformation": "Monitoring NACL changes helps ensure that network traffic controls remain properly configured and that AWS resources are not unintentionally exposed. Unauthorized or accidental modifications to NACL rules can lead to misconfigured security policies, increased attack surfaces, and potential data breaches. Real-time alerts enable security teams to detect, investigate, and respond to NACL modifications quickly, maintaining strong network security controls.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.13", + "Description": "Ensure changes to network gateways are monitored", + "Checks": [ + "cloudwatch_changes_to_network_gateways_alarm_configured" + ], + "Attributes": [ + { + "Title": "Changes to network gateways are monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be implemented by forwarding CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. Network gateways serve as the primary route for traffic entering and leaving a VPC, facilitating communication with external networks. It is recommended to establish a metric filter and alarm for changes to network gateways to ensure that network traffic is securely routed through controlled paths.", + "AdditionalInformation": "Monitoring network gateway changes helps maintain secure ingress and egress traffic flows within a VPC. Unauthorized or accidental modifications to network gateways can disrupt connectivity, introduce security vulnerabilities, or expose AWS resources to external threats. Real-time alerts enable security teams to detect, investigate, and respond to changes quickly, ensuring that all traffic follows a controlled and secure routing policy.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.14", + "Description": "Ensure route table changes are monitored", + "Checks": [ + "cloudwatch_changes_to_network_route_tables_alarm_configured" + ], + "Attributes": [ + { + "Title": "Route table changes are monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be achieved by forwarding CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. Route tables determine how network traffic is directed between subnets and network gateways within a VPC. It is recommended to establish a metric filter and alarm for changes to route tables to detect unauthorized or accidental modifications that could impact network security and connectivity.", + "AdditionalInformation": "Monitoring route table changes ensures that VPC traffic follows the intended and secure routing paths. Unauthorized modifications can result in misrouted traffic, exposure of sensitive resources, or connectivity disruptions. Real-time alerts enable security teams to detect, investigate, and respond to route table changes promptly, preventing potential security risks and maintaining a controlled and secure network environment.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.15", + "Description": "Ensure VPC changes are monitored", + "Checks": [ + "cloudwatch_changes_to_vpcs_alarm_configured" + ], + "Attributes": [ + { + "Title": "VPC changes are monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be implemented by forwarding CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. AWS accounts can contain multiple Virtual Private Clouds (VPCs), and VPC peering connections allow network traffic to flow between them. It is recommended to establish a metric filter and alarm for changes made to VPC configurations to detect unauthorized modifications that could impact network security and connectivity.", + "AdditionalInformation": "Monitoring VPC configuration changes helps ensure network integrity, security, and proper traffic flow within AWS environments. Unauthorized or accidental modifications can result in misconfigured routing, unintended internet exposure, or connectivity disruptions between resources. Real-time alerts enable security teams to detect, investigate, and respond to VPC changes promptly, preventing security risks and ensuring consistent network accessibility and isolation.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.16", + "Description": "Ensure AWS Organizations changes are monitored", + "Checks": [ + "cloudwatch_log_metric_filter_aws_organizations_changes" + ], + "Attributes": [ + { + "Title": "AWS Organizations changes are monitored", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Real-time monitoring of AWS API calls can be achieved by forwarding CloudTrail logs to Amazon CloudWatch Logs or an external Security Information and Event Management (SIEM) system. AWS Organizations allows centralized management of multiple AWS accounts, and modifications to its configuration can significantly impact access control, account governance, and security policies. It is recommended to establish a metric filter and alarm for changes made to AWS Organizations in the master AWS account to detect unauthorized or unintended modifications.", + "AdditionalInformation": "Monitoring AWS Organizations configuration changes helps prevent unwanted, accidental, or malicious modifications that could lead to unauthorized access, policy misconfigurations, or security breaches. Detecting changes in real time ensures that unexpected modifications can be investigated and remediated quickly, reducing the risk of compromised governance structures and ensuring compliance with organizational security policies.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.17", + "Description": "Ensure AWS Security Hub is enabled", + "Checks": [ + "securityhub_enabled" + ], + "Attributes": [ + { + "Title": "Security Hub enabled", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "AWS Security Hub centralizes security data from multiple AWS services and third-party security tools, allowing for real-time threat detection, risk assessment, and compliance monitoring. When enabled, Security Hub aggregates, organizes, and prioritizes security findings from services such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie, as well as integrated third-party security products. This provides organizations with a unified security management platform to enhance threat visibility.", + "AdditionalInformation": "Enabling AWS Security Hub provides a comprehensive view of your security posture, helping to identify vulnerabilities, detect threats, and enforce security best practices. It allows organizations to monitor security trends, benchmark environments against industry standards, and quickly respond to high-priority security issues, strengthening overall AWS security governance and compliance.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.2.2", + "Description": "Ensure CloudWatch Log Groups have a retention policy of specific days", + "Checks": [ + "cloudwatch_log_group_retention_policy_specific_days_enabled" + ], + "Attributes": [ + { + "Title": "CloudWatch Log Groups have a retention policy of specific days", + "Section": "3. Logging and Monitoring", + "SubSection": "3.2 Retention", + "AttributeDescription": "AWS CloudWatch Log Groups store logs from various AWS services and applications, enabling monitoring, debugging, and security auditing. By default, CloudWatch logs are retained indefinitely, which can lead to unnecessary data storage costs and compliance risks. To manage log lifecycle effectively, it is recommended to set a retention policy for CloudWatch Log Groups, ensuring logs are retained only for a specific number of days based on operational and compliance requirements.", + "AdditionalInformation": "Setting a retention policy for CloudWatch logs helps balance cost management, compliance, and security. Retaining logs for too long increases storage costs and potential exposure to sensitive data, while keeping them for too short a duration can limit forensic investigations and compliance reporting. By defining a specific retention period, organizations can ensure logs are available for troubleshooting and audits while adhering to data retention best practices and regulatory requirements.", + "LevelOfRisk": 1 + } + ] + } + ] +} diff --git a/prowler/compliance/azure/prowler_threatscore_azure.json b/prowler/compliance/azure/prowler_threatscore_azure.json new file mode 100644 index 0000000000..db479fb616 --- /dev/null +++ b/prowler/compliance/azure/prowler_threatscore_azure.json @@ -0,0 +1,1317 @@ +{ + "Framework": "ProwlerThreatScore", + "Version": "1.0", + "Provider": "Azure", + "Description": "Prowler ThreatScore Compliance Framework for Azure ensures that the Azure subscription is compliant taking into account four main pillars: Identity and Access Management, Attack Surface, Forensic Readiness and Encryption", + "Requirements": [ + { + "Id": "1.1.1", + "Description": "Ensure Security Defaults is enabled on Microsoft Entra ID", + "Checks": [ + "entra_security_defaults_enabled" + ], + "Attributes": [ + { + "Title": "Security Defaults enabled on Entra ID", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "Microsoft Entra ID Security Defaults offer preconfigured security settings designed to protect organizations from common identity attacks at no additional cost. These settings enforce basic security measures such as MFA registration, risk-based authentication prompts, and blocking legacy authentication clients that do not support MFA. Security defaults are available to all organizations and can be enabled via the Azure portal to strengthen authentication security.", + "AdditionalInformation": "Security defaults provide built-in protections to reduce the risk of unauthorized access until organizations configure their own identity security policies. By requiring MFA, blocking weak authentication methods, and adapting authentication challenges based on risk factors, these settings create a stronger security foundation without additional licensing requirements.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "1.1.2", + "Description": "Ensure that 'Multi-Factor Auth Status' is 'Enabled' for all Privileged Users", + "Checks": [ + "entra_privileged_user_has_mfa" + ], + "Attributes": [ + { + "Title": "MFA enabled for privileged users", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "[IMPORTANT] If your organization has Microsoft Entra ID licensing (included in Microsoft 365 E3, E5, F5, or EM&S E3/E5) and can use Conditional Access, you may skip this section and proceed to Conditional Access. Enable multi-factor authentication (MFA) for all users, roles, and groups with write access to Azure resources. This includes both custom-created roles and built-in roles such as: Service Co-Administrators, Subscription Owners, Contributors", + "AdditionalInformation": "MFA enhances security by requiring two or more authentication factors, ensuring that only authorized users gain access. It significantly reduces the risk of unauthorized access, credential theft, and privilege escalation. By implementing MFA, attackers must compromise multiple authentication mechanisms, making breaches far more difficult and improving overall Azure resource security.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "1.1.3", + "Description": "Ensure that 'Multi-Factor Auth Status' is 'Enabled' for all Non-Privileged Users", + "Checks": [ + "entra_non_privileged_user_has_mfa" + ], + "Attributes": [ + { + "Title": "MFA enabled for non-privileged users", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "[IMPORTANT] If your organization has Microsoft Entra ID licensing (included in Microsoft 365 E3, E5, F5, or EM&S E3/E5) and can use Conditional Access, you may skip this section and proceed to Conditional Access. Enable multi-factor authentication (MFA) for all non-privileged users to enhance security and prevent unauthorized access.", + "AdditionalInformation": "MFA strengthens authentication by requiring at least two verification factors, making it significantly harder for attackers to gain access using stolen credentials. Even if one authentication factor is compromised, an additional layer of security reduces the risk of unauthorized account access, enhancing overall identity and access management security.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "1.1.4", + "Description": "Ensure Multi-factor Authentication is Required for Windows Azure Service Management API", + "Checks": [ + "entra_conditional_access_policy_require_mfa_for_management_api" + ], + "Attributes": [ + { + "Title": "MFA Required for Windows Azure Service Management API", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "This recommendation ensures that users accessing the Windows Azure Service Management API (e.g., Azure PowerShell, Azure CLI, Azure Resource Manager API) are required to authenticate using multi-factor authentication (MFA) before accessing resources.", + "AdditionalInformation": "Administrative access to the Azure Service Management API should be secured with enhanced authentication measures to prevent unauthorized changes. Enforcing MFA helps mitigate the risk of credential compromise, privilege abuse, and unauthorized modifications to administrative settings. IMPORTANT: While exceptions for specific users or groups may be configured, they should be carefully tracked and periodically reviewed through an Access Review process. The policy should apply to all users by default, ensuring that only explicitly exempted accounts bypass MFA.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "1.1.5", + "Description": "Ensure Multi-factor Authentication is Required to access Microsoft Admin Portals", + "Checks": [ + "defender_ensure_defender_for_server_is_on" + ], + "Attributes": [ + { + "Title": "MFA Required to access Microsoft Admin Portals", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "This recommendation ensures that users accessing Microsoft Admin Portals (such as Microsoft 365 Admin, Microsoft 365 Defender, Exchange Admin Center, and Azure Portal) must authenticate using multi-factor authentication (MFA) before logging in.", + "AdditionalInformation": "Microsoft Admin Portals provide privileged access to critical settings and resources, requiring enhanced security measures. Enforcing MFA reduces the risk of unauthorized access, credential compromise, and administrative abuse, preventing intruders from making unauthorized changes to administrative settings.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.1.6", + "Description": "Ensure only MFA enabled identities can access privileged Virtual Machine", + "Checks": [ + "entra_user_with_vm_access_has_mfa" + ], + "Attributes": [ + { + "Title": "Only MFA enabled identities can access privileged Virtual Machine", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "Ensure that privileged virtual machines do not allow logins from identities without multi-factor authentication (MFA) and that access is restricted to necessary permissions only. Unauthorized access can enable attackers to move laterally and misuse the virtual machine’s managed identity for further privilege escalation or unauthorized operations.", + "AdditionalInformation": "Requiring MFA for privileged VM access reduces the risk of credential compromise, lateral movement, and unauthorized access to cloud resources. Attackers can exploit valid accounts to access virtual machines and escalate privileges using the managed identity. Enforcing MFA and least privilege access helps mitigate these risks by preventing unauthorized logins and restricting administrative permissions to only what is necessary.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "1.2.1", + "Description": "Ensure that 'Restrict non-admin users from creating tenants' is set to 'Yes'", + "Checks": [ + "entra_policy_ensure_default_user_cannot_create_tenants" + ], + "Attributes": [ + { + "Title": "Restrict non-admin users from creating tenants is set to Yes", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "Restrict the ability to create new Microsoft Entra ID or Azure AD B2C tenants to administrators or appropriately delegated users.", + "AdditionalInformation": "Limiting tenant creation to authorized administrators prevents unauthorized users from creating new tenants, reducing the risk of uncontrolled environments, misconfigurations, and potential security gaps. This ensures that only approved users can establish and manage tenant resources.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.2.2", + "Description": "Ensure fewer than 5 users have global administrator assignment", + "Checks": [ + "entra_global_admin_in_less_than_five_users" + ], + "Attributes": [ + { + "Title": "Fewer than 5 users have global administrator assignment", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "To maintain security and operational efficiency, it is recommended to have a minimum of two and a maximum of four users assigned the Global Administrator role in Microsoft Entra ID. This ensures redundancy while minimizing the risk of excessive privileged access.", + "AdditionalInformation": "The Global Administrator role holds broad privileges across Microsoft Entra ID services and should not be used for daily tasks. Administrators should have separate accounts for regular activities and privileged actions. Limiting the number of Global Administrators reduces the risk of unauthorized access, human error, and privilege misuse, while ensuring at least two administrators are available to prevent disruptions in case of unavailability. This approach aligns with the principle of least privilege and strengthens the security posture of an Azure tenant.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.2.3", + "Description": "Ensure That 'Guest users access restrictions' is set to 'Guest user access is restricted to properties and memberships of their own directory objects'", + "Checks": [ + "entra_policy_guest_users_access_restrictions" + ], + "Attributes": [ + { + "Title": "Guest users access restrictions' is set to 'Guest user access is restricted to properties and memberships of their own directory objects'", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "Restrict guest user permissions to prevent unauthorized access to directory resources and administrative roles.", + "AdditionalInformation": "Limiting guest access ensures that guest accounts cannot enumerate users, groups, or directory objects and prevents them from being assigned administrative roles. Guest access has three levels of restriction, with the most secure option being: “Guest user access is restricted to their own directory object” (most restrictive). This setting minimizes the risk of unauthorized access and ensures guests only interact with their assigned resources.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.2.4", + "Description": "Ensure `User consent for applications` is set to `Do not allow user consent` ", + "Checks": [ + "entra_policy_restricts_user_consent_for_apps" + ], + "Attributes": [ + { + "Title": "`User consent for applications` is set to `Do not allow user consent` ", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "Require administrators to provide consent before applications can access Microsoft Entra ID resources, preventing unauthorized or malicious app integrations.", + "AdditionalInformation": "Allowing users to grant application permissions without restrictions increases the risk of data exfiltration and privilege abuse by malicious applications. Restricting app consent to administrators ensures that only verified and approved applications gain access, protecting sensitive data and privileged accounts from unauthorized use.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.2.5", + "Description": "Ensure ‘User consent for applications’ Is Set To ‘Allow for Verified Publishers’", + "Checks": [ + "entra_policy_user_consent_for_verified_apps" + ], + "Attributes": [ + { + "Title": "‘User consent for applications’ Is Set To ‘Allow for Verified Publishers’", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "Allow users to grant consent only for selected permissions when the request comes from a verified publisher, ensuring tighter control over third-party application access.", + "AdditionalInformation": "Restricting app consent to verified publishers helps mitigate the risk of unauthorized data access and privilege abuse. Malicious applications may attempt to exploit user-granted permissions, so ensuring only trusted, verified applications can request access enhances security while maintaining flexibility for approved integrations.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.2.6", + "Description": "Ensure Trusted Locations Are Defined", + "Checks": [ + "entra_trusted_named_locations_exists" + ], + "Attributes": [ + { + "Title": "Trusted Locations Are Defined", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "Microsoft Entra ID Conditional Access allows organizations to define Named Locations and categorize them as trusted or untrusted. These locations can be based on geographical regions, specific IP addresses, or IP ranges to enhance access control policies.", + "AdditionalInformation": "Defining trusted IP addresses or ranges enables organizations to enforce Conditional Access policies based on user location. Users authenticating from trusted locations may receive fewer access restrictions, while those from untrusted sources can be subject to stricter security controls, reducing the risk of unauthorized access.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.3.1", + "Description": "Ensure that 'Users can create security groups in Azure portals, API or PowerShell' is set to 'No'", + "Checks": [ + "entra_policy_default_users_cannot_create_security_groups" + ], + "Attributes": [ + { + "Title": "Users can create security groups in Azure portals, API or PowerShell' is set to 'No'", + "Section": "1. IAM", + "SubSection": "1.3 Privilege Escalation Prevention", + "AttributeDescription": "Limit the ability to create security groups to administrators only, preventing unauthorized users from managing group memberships.", + "AdditionalInformation": "Allowing all users to create and manage security groups can lead to uncontrolled access, misconfigurations, and potential security risks. Unless business requirements justify broader delegation, restricting security group creation to administrators ensures that group permissions and memberships are properly managed, reducing the risk of unauthorized access.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.3.2", + "Description": "Ensure That ‘Users Can Register Applications’ Is Set to ‘No’", + "Checks": [ + "entra_policy_ensure_default_user_cannot_create_apps" + ], + "Attributes": [ + { + "Title": "‘Users Can Register Applications’ Is Set to ‘No’", + "Section": "1. IAM", + "SubSection": "1.3 Privilege Escalation Prevention", + "AttributeDescription": "Restrict the ability to register third-party applications to administrators or appropriately delegated users, ensuring better security control over app integrations.", + "AdditionalInformation": "Allowing unrestricted application registration can expose Microsoft Entra ID data to security risks. Requiring administrator approval ensures that custom-developed applications undergo a formal security review before being granted access. Organizations may delegate permissions to developers or high-request users as needed, but policies should be reviewed to align with security best practices and operational needs.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.3.3", + "Description": "Ensure that 'Guest invite restrictions' is set to 'Only users assigned to specific admin roles can invite guest users'", + "Checks": [ + "entra_policy_guest_invite_only_for_admin_roles" + ], + "Attributes": [ + { + "Title": "Guest invite restrictions' is set to 'Only users assigned to specific admin roles can invite guest users'", + "Section": "1. IAM", + "SubSection": "1.3 Privilege Escalation Prevention", + "AttributeDescription": "Limit the ability to send invitations to users with specific administrative roles, preventing unauthorized guest access to cloud resources.", + "AdditionalInformation": "Restricting guest invitations to designated administrators helps enforce “Need to Know” permissions, reducing the risk of unintended data exposure. By default, anyone in the organization—including guests and non-admins—can invite external users, which can lead to unauthorized access. Restricting this capability ensures that only approved accounts can extend access to the tenant, strengthening security and access control.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "1.3.4", + "Description": "Ensure that 'Users can create Microsoft 365 groups in Azure portals, API or PowerShell' is set to 'No'", + "Checks": [ + "entra_users_cannot_create_microsoft_365_groups" + ], + "Attributes": [ + { + "Title": "Users can create Microsoft 365 groups in Azure portals, API or PowerShell' is set to 'No'", + "Section": "1. IAM", + "SubSection": "1.3 Privilege Escalation Prevention", + "AttributeDescription": "Limit Microsoft 365 group creation to administrators only, ensuring that group management remains under centralized control.", + "AdditionalInformation": "Restricting group creation to administrators prevents unauthorized or unnecessary group creation, ensuring that only appropriate groups are created and managed. This reduces the risk of misconfigurations, access issues, and uncontrolled resource sharing within the organization.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.1.1", + "Description": "Ensure that RDP access from the Internet is evaluated and restricted", + "Checks": [ + "network_rdp_internet_access_restricted" + ], + "Attributes": [ + { + "Title": "RDP access from the Internet is evaluated and restricted", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "Regularly review Network Security Groups (NSGs) for misconfigured or overly permissive rules, especially those exposing ports and protocols to the public internet. Any unnecessary exposure should be restricted to reduce security risks.", + "AdditionalInformation": "Exposing Remote Desktop Protocol (RDP) or other critical services to the internet increases the risk of brute-force attacks, which could lead to unauthorized access to Azure Virtual Machines. Compromised VMs can be used to launch attacks on other networked resources, both inside and outside Azure. Periodic NSG evaluations help minimize attack surfaces and ensure that only explicitly required access is permitted.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.1.2", + "Description": "Ensure that SSH access from the Internet is evaluated and restricted", + "Checks": [ + "network_ssh_internet_access_restricted" + ], + "Attributes": [ + { + "Title": "SSH access from the Internet is evaluated and restricted", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "Regularly review Network Security Groups (NSGs) for misconfigured or overly permissive rules, particularly those exposing SSH (port 22) or other critical services to the internet. Any unnecessary exposure should be restricted to reduce security risks.", + "AdditionalInformation": "Exposing SSH over the internet increases the risk of brute-force attacks, allowing attackers to gain unauthorized access to Azure Virtual Machines. Once compromised, a VM can be used as a pivot point to attack other machines within the Azure Virtual Network or even external systems. Periodic NSG evaluations help minimize attack surfaces and ensure that only explicitly required access is permitted.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.1.3", + "Description": "Ensure that UDP access from the Internet is evaluated and restricted", + "Checks": [ + "network_udp_internet_access_restricted" + ], + "Attributes": [ + { + "Title": "UDP access from the Internet is evaluated and restricted", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "Regularly review Network Security Groups (NSGs) for misconfigured or overly permissive UDP rules, especially those exposing UDP-based services to the internet. Any unnecessary exposure should be restricted to prevent security risks.", + "AdditionalInformation": "Exposing UDP services to the internet increases the risk of Distributed Denial-of-Service (DDoS) amplification attacks, where attackers can reflect and amplify spoofed traffic from Azure Virtual Machines. Commonly exploited UDP services include DNS, NTP, SSDP, SNMP, and CLDAP, which can be used to disrupt services or launch attacks against other networked systems inside and outside Azure. Regular NSG evaluations help minimize attack surfaces and prevent VMs from being leveraged in DDoS attacks.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.1.4", + "Description": "Ensure that HTTP(S) access from the Internet is evaluated and restricted", + "Checks": [ + "network_http_internet_access_restricted" + ], + "Attributes": [ + { + "Title": "HTTP(S) access from the Internet is evaluated and restricted", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "Regularly review Network Security Groups (NSGs) for misconfigured or overly permissive HTTP(S) rules, ensuring that exposure to the internet is necessary and narrowly configured. Restrict access where it is not explicitly required.", + "AdditionalInformation": "Exposing HTTP(S) services to the internet increases the risk of brute-force attacks, credential stuffing, and exploitation of vulnerabilities in web applications or services. If compromised, an attacker can use the affected resource as a pivot point to escalate privileges, move laterally, and compromise other Azure resources within the tenant. Periodic NSG evaluations help reduce attack surfaces and enforce least privilege access.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.1.5", + "Description": "Ensure an Azure Bastion Host Exists", + "Checks": [ + "network_bastion_host_exists" + ], + "Attributes": [ + { + "Title": "Ensure Azure Bastion Host Exists", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "Enable Azure Bastion to securely access Azure Virtual Machines (VMs) over the internet without exposing RDP (3389/TCP) or SSH (22/TCP) ports directly to the public network. Azure Bastion provides remote access through TLS (443/TCP) while integrating with Azure Active Directory (AAD) security policies.", + "AdditionalInformation": "Using Azure Bastion eliminates the need to assign public IP addresses to VMs, reducing exposure to brute-force attacks and unauthorized access. It enhances security by enabling browser-based RDP/SSH access, leveraging Azure Active Directory controls, and supporting Multi-Factor Authentication (MFA), Conditional Access Policies, and other hardening measures for a centralized and secure access solution.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "2.2.1", + "Description": "Ensure that Microsoft Entra authentication is Configured for SQL Servers", + "Checks": [ + "sqlserver_azuread_administrator_enabled" + ], + "Attributes": [ + { + "Title": "Microsoft Entra authentication is Configured for SQL Servers", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Use Microsoft Entra authentication for SQL Database to centralize identity and credential management, enhancing security and simplifying access control. By leveraging Microsoft Entra ID, organizations can manage database users, permissions, and authentication policies in a single location, reducing complexity and improving security.", + "AdditionalInformation": "Microsoft Entra authentication eliminates the need for separate SQL authentication, preventing identity sprawl and simplifying password management. It enables centralized permission management, supports token-based authentication, integrates with Active Directory Federation Services (ADFS), and enhances security with Multi-Factor Authentication (MFA). Using Entra ID authentication also eliminates the need to store passwords, enabling secure, modern authentication methods while ensuring seamless access control for users and applications.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "2.2.2", + "Description": "Ensure 'Allow public access from any Azure service within Azure to this server' for PostgreSQL flexible server is disabled ", + "Checks": [ + "postgresql_flexible_server_allow_access_services_disabled" + ], + "Attributes": [ + { + "Title": "Allow public access from any Azure service within Azure to this server' for PostgreSQL flexible server is disabled ", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Disable access from Azure services to PostgreSQL flexible servers to restrict inbound connections and enhance security.", + "AdditionalInformation": "Allowing access from all Azure services bypasses firewall restrictions and permits connections from any Azure resource, including those outside your subscription. This can expose the database to unauthorized access and security risks. Instead, configure firewall rules or Virtual Network (VNet) rules to allow only specific, trusted network ranges, ensuring tighter access control.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.3", + "Description": "Ensure That 'Firewalls & Networks' Is Limited to Use Selected Networks Instead of All Networks", + "Checks": [ + "cosmosdb_account_firewall_use_selected_networks" + ], + "Attributes": [ + { + "Title": "Firewalls & Networks' Is Limited to Use Selected Networks Instead of All Networks", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Restrict Cosmos DB access to whitelisted networks to minimize exposure and reduce potential attack vectors.", + "AdditionalInformation": "Limiting Cosmos DB communication to specific trusted networks prevents unauthorized access from unapproved sources, including the public internet. This enhances security by reducing the attack surface and ensuring only designated networks can interact with the database.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "2.2.4", + "Description": "Ensure That Private Endpoints Are Used Where Possible", + "Checks": [ + "cosmosdb_account_use_private_endpoints" + ], + "Attributes": [ + { + "Title": "Private Endpoints Are Used", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Use private endpoints for Cosmos DB to restrict network traffic to approved sources, ensuring secure and private communication.", + "AdditionalInformation": "For sensitive data, private endpoints provide granular control over which services can access Cosmos DB, preventing exposure to unauthorized networks. This setup ensures that all traffic remains within a private network, reducing security risks and enhancing data protection.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.5", + "Description": "Use Entra ID Client Authentication and Azure RBAC where possible", + "Checks": [ + "cosmosdb_account_use_aad_and_rbac" + ], + "Attributes": [ + { + "Title": "Entra ID Client Authentication and Azure RBAC where possible", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Use Microsoft Entra ID for Cosmos DB client authentication, leveraging Azure RBAC for enhanced security, centralized management, and MFA support.", + "AdditionalInformation": "Entra ID authentication is significantly more secure than token-based authentication, as tokens must be stored persistently on the client, increasing the risk of compromise. Entra ID eliminates this risk by securely handling credentials, integrating seamlessly with Azure RBAC, and supporting multi-factor authentication (MFA) for stronger access control.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "2.2.6", + "Description": "Ensure that 'Public Network Access' is 'Disabled' for storage accounts", + "Checks": [ + "storage_blob_public_access_level_is_disabled" + ], + "Attributes": [ + { + "Title": "Public Network Access' is 'Disabled' for storage accounts", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Disable public network access for Azure Storage accounts, ensuring that access settings for individual containers cannot override this restriction. This applies to Azure Resource Manager deployment model storage accounts, as classic deployment model accounts will be retired by August 31, 2024.", + "AdditionalInformation": "By default, Azure Storage accounts allow users with appropriate permissions to enable public access to containers and blobs, granting read-only access without requiring authentication. To minimize the risk of unauthorized data exposure, public access should be restricted unless explicitly required. Instead, use Azure AD RBAC or shared access signatures (SAS) to grant controlled and time-limited access to storage resources.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "2.2.7", + "Description": "Ensure Default Network Access Rule for Storage Accounts is Set to Deny", + "Checks": [ + "storage_default_network_access_rule_is_denied" + ], + "Attributes": [ + { + "Title": "Default Network Access Rule for Storage Accounts is Set to Deny", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Restricting default network access enhances security by preventing unrestricted connections to Azure Storage accounts. By default, storage accounts accept connections from any network, so access should be limited to selected networks by modifying the default configuration.", + "AdditionalInformation": "Storage accounts should deny access from all networks by default, except for explicitly allowed Azure Virtual Networks or specific IP address ranges. This approach creates a secure network boundary, ensuring only authorized applications can connect. Even when network rules allow access, proper authentication (via access keys or SAS tokens) is still required, adding an extra layer of security.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.8", + "Description": "Ensure 'Allow Azure services on the trusted services list to access this storage account' is Enabled for Storage Account Access", + "Checks": [ + "storage_ensure_azure_services_are_trusted_to_access_is_enabled" + ], + "Attributes": [ + { + "Title": "Allow Azure services on the trusted services list to access this storage account' is Enabled for Storage Account Access", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "This recommendation assumes that public network access is set to “Enabled from selected virtual networks and IP addresses” and that the default network access rule for storage accounts is set to deny. Some Azure services require access to storage accounts from networks that cannot be explicitly granted permissions through network rules. To allow these services to function properly, enable the trusted Azure services exception, which allows selected Azure services to bypass network restrictions while still enforcing strong authentication.", + "AdditionalInformation": "Enabling firewall rules on a storage account blocks access to all incoming requests, including those from other Azure services. Allowing access to trusted Azure services ensures that essential Azure functions, such as Azure Backup, Event Grid, Monitor, and Site Recovery, can interact with storage accounts securely without exposing them to broader public access.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "2.2.9", + "Description": "Ensure Private Endpoints are used to access Storage Accounts", + "Checks": [ + "storage_ensure_private_endpoints_in_storage_accounts" + ], + "Attributes": [ + { + "Title": "Private Endpoint used to access Storage Accounts", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Use private endpoints for Azure Storage accounts to enable secure, encrypted access over a Private Link. Private endpoints assign an IP address from the Virtual Network (VNet) for each service, ensuring that network traffic remains isolated and encrypted within the VNet. This configuration helps segment network traffic, preventing external access while allowing secure communication between services. Additionally, VNets can extend addressing spaces or act as secure tunnels over public networks, connecting remote infrastructures securely.", + "AdditionalInformation": "Encrypting traffic between services protects sensitive data from interception and unauthorized access. Using private endpoints ensures that data remains within a controlled network environment, reducing exposure to external threats and enhancing overall security posture.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "2.2.10", + "Description": "Ensure no Azure SQL Databases allow ingress from 0.0.0.0/0", + "Checks": [ + "sqlserver_unrestricted_inbound_access" + ], + "Attributes": [ + { + "Title": "Azure SQL Databases do not allow ingress from 0.0.0.0/0", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Ensure that Azure SQL Databases do not allow ingress from 0.0.0.0/0 (ANY IP), as this would expose them to the public internet. Azure SQL Server includes a firewall that blocks unauthorized connections by default, but it allows defining more granular IP address rules to restrict access. Allowing 0.0.0.0/0 effectively grants open access, increasing security risks.", + "AdditionalInformation": "Leaving Azure SQL firewall rules open to ANY IP significantly increases the attack surface, making databases vulnerable to brute-force attacks and unauthorized access. Instead, firewall rules should be restricted to specific, trusted IP ranges from known datacenters or internal resources. Additionally, enabling Allow Azure services and resources to access this server could allow access from outside your organization’s subscription or region, potentially bypassing SQL Server’s network ACLs and exposing the database to malicious activity.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "2.3.1", + "Description": "Ensure App Service Authentication is set up for apps in Azure App Service", + "Checks": [ + "app_ensure_auth_is_set_up" + ], + "Attributes": [ + { + "Title": "App Service Authentication is set up for apps in Azure App Service", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Enable Azure App Service Authentication to restrict anonymous HTTP requests and enforce authentication using identity providers before requests reach the application.", + "AdditionalInformation": "Enabling App Service Authentication ensures that all incoming HTTP requests are validated and authenticated before being processed by the application. It integrates with Microsoft Entra ID, Google, Facebook, Microsoft Accounts, and Twitter to manage authentication, token validation, and session handling. Additionally, disabling HTTP Basic Authentication helps mitigate risks from legacy authentication methods, strengthening application security.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "2.3.2", + "Description": "Ensure 'FTP State' is set to 'FTPS Only' or 'Disabled' ", + "Checks": [ + "app_ftp_deployment_disabled" + ], + "Attributes": [ + { + "Title": "FTP State' is set to 'FTPS Only' or 'Disabled' ", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Ensure that FTP access is disabled for Azure App Services, or if required, enforce FTPS (FTP over SSL/TLS) for secure authentication and data transmission.", + "AdditionalInformation": "FTP transmits data, including credentials, in plaintext, making it vulnerable to interception, credential theft, and data exfiltration. Requiring FTPS ensures that all FTP connections are encrypted, reducing the risk of unauthorized access, persistence, and lateral movement within the environment. If FTP is not needed, disabling it entirely enhances security by eliminating an unnecessary attack vector.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "3.1.1", + "Description": "Ensure server parameter 'log_checkpoints' is set to 'ON' for PostgreSQL flexible server", + "Checks": [ + "postgresql_flexible_server_log_checkpoints_on" + ], + "Attributes": [ + { + "Title": "log_checkpoints' is set to 'ON' for PostgreSQL flexible server", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "Enable log_checkpoints on PostgreSQL flexible servers to log checkpoint activity, generating query and error logs that aid in monitoring and troubleshooting database performance.", + "AdditionalInformation": "Logging checkpoints helps track database activity, errors, and performance issues, providing valuable insights for troubleshooting and optimization. While transaction logs remain inaccessible, query and error logs allow identification and resolution of configuration errors and inefficiencies, improving database reliability and performance.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.1.2", + "Description": "Ensure server parameter 'connection_throttle.enable' is set to 'ON' for PostgreSQL flexible server", + "Checks": [ + "postgresql_flexible_server_connection_throttling_on" + ], + "Attributes": [ + { + "Title": "connection_throttle.enable' is set to 'ON' for PostgreSQL flexible server", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "Enable connection throttling on PostgreSQL flexible servers to regulate concurrent connections and generate logs for monitoring and troubleshooting.", + "AdditionalInformation": "Connection throttling helps prevent Denial of Service (DoS) attacks by limiting excessive connections that could exhaust resources. It also protects against system failures or degraded performance caused by high user loads. Query and error logs provide insights into connection issues, enabling faster troubleshooting and performance optimization.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.1.3", + "Description": "Ensure server parameter 'log_connections' is set to 'ON' for PostgreSQL single server", + "Checks": [ + "postgresql_flexible_server_log_connections_on" + ], + "Attributes": [ + { + "Title": "log_connections' is set to 'ON' for PostgreSQL single server", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "Enable log_connections on PostgreSQL Single Servers to record connection attempts and authentication events for security monitoring and auditing. (Note: This recommendation applies only to Single Server, as Azure PostgreSQL Single Server is planned for retirement.)", + "AdditionalInformation": "Logging connection attempts helps detect unauthorized access, failed authentication attempts, and potential security threats. These logs provide valuable insights for troubleshooting, auditing, and identifying suspicious activities, enhancing overall database security and monitoring.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.1.4", + "Description": "Ensure server parameter 'log_disconnections' is set to 'ON' for PostgreSQL single server", + "Checks": [ + "postgresql_flexible_server_log_disconnections_on" + ], + "Attributes": [ + { + "Title": "log_disconnections' is set to 'ON' for PostgreSQL single server", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "Enable log_disconnections on PostgreSQL Servers to record session termination events, including session duration. (Note: This recommendation applies only to Single Server, as Azure PostgreSQL Single Server is planned for retirement.)", + "AdditionalInformation": "Logging disconnections provides visibility into session activity and duration, helping to analyze user behavior, detect anomalies, and troubleshoot performance issues. These logs contribute to audit trails, security monitoring, and database performance optimization.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.1.5", + "Description": "Ensure server parameter 'audit_log_enabled' is set to 'ON' for MySQL flexible server", + "Checks": [ + "mysql_flexible_server_audit_log_enabled" + ], + "Attributes": [ + { + "Title": "audit_log_enabled' is set to 'ON' for MySQL flexible server", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "Enable audit_log_enabled on MySQL flexible servers to capture logs for connection attempts, DDL/DML activity, and other database events for security and monitoring purposes.", + "AdditionalInformation": "Logging database activity helps detect unauthorized access, troubleshoot issues, and analyze performance bottlenecks. Enabling audit logs enhances security visibility, compliance monitoring, and incident response by providing valuable insights into database operations.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.1.6", + "Description": "Ensure server parameter 'audit_log_events' has 'CONNECTION' set for MySQL flexible server", + "Checks": [ + "mysql_flexible_server_audit_log_connection_activated" + ], + "Attributes": [ + { + "Title": "audit_log_events' has 'CONNECTION' set for MySQL flexible server", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "Configure audit_log_events on MySQL flexible servers to include CONNECTION events, ensuring that successful and failed connection attempts are logged.", + "AdditionalInformation": "Logging CONNECTION events provides visibility into authentication attempts, helping to detect unauthorized access, troubleshoot issues, and optimize database performance. These logs are essential for security monitoring, compliance, and identifying potential misconfigurations or attack attempts.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.1.7", + "Description": "Ensure that logging for Azure Key Vault is 'Enabled' ", + "Checks": [ + "keyvault_logging_enabled" + ], + "Attributes": [ + { + "Title": "Logging for Azure Keyvault enabled", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "Enable AuditEvent logging for Azure Key Vault to track and log interactions with keys, certificates, and other sensitive information.", + "AdditionalInformation": "Logging Key Vault access events provides an audit trail that helps monitor who accessed the vault, when, and how. This enhances security, compliance, and incident response by ensuring logs are stored in a designated Azure Storage account or Log Analytics workspace, allowing centralized monitoring across multiple Key Vaults.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.1.8", + "Description": "Ensure that Network Security Group Flow logs are captured and sent to Log Analytics", + "Checks": [ + "network_flow_log_captured_sent" + ], + "Attributes": [ + { + "Title": "Network Security Group Flow logs are captured and sent to Log Analytics", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "Ensure that network flow logs are collected and sent to a central Log Analytics workspace for monitoring and analysis.", + "AdditionalInformation": "Capturing network flow logs provides visibility into traffic patterns across your network, helping detect anomalies, potential lateral movement, and security threats. These logs integrate with Azure Monitor and Azure Sentinel, enabling advanced analytics and visualization for improved network security and incident response.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.1.9", + "Description": "Ensure that logging for Azure AppService 'HTTP logs' is enabled", + "Checks": [ + "app_http_logs_enabled" + ], + "Attributes": [ + { + "Title": "Logging for Azure AppService 'HTTP logs' is enabled", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "Enable AppServiceHTTPLogs for Azure App Service instances to capture and centrally log all HTTP requests.", + "AdditionalInformation": "Logging web requests provides critical data for security monitoring and incident response. Captured logs can be ingested into a SIEM or central log aggregation system, helping security analysts detect anomalies, investigate threats, and enhance application security.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.2.1", + "Description": "Ensure that 'Auditing' Retention is 'greater than 90 days'", + "Checks": [ + "sqlserver_auditing_retention_90_days" + ], + "Attributes": [ + { + "Title": "Auditing' Retention is 'greater than 90 days'", + "Section": "3. Logging and Monitoring", + "SubSection": "3.2 Retention", + "AttributeDescription": "Configure SQL Server Audit Retention to retain logs for more than 90 days to ensure long-term visibility into database activity and security events.", + "AdditionalInformation": "Maintaining audit logs for over 90 days helps detect anomalies, security breaches, and unauthorized access. Longer retention periods allow organizations to analyze historical data, support compliance requirements, and strengthen forensic investigations.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.2.1", + "Description": "Ensure that Network Security Group Flow Log retention period is 'greater than 90 days'", + "Checks": [ + "network_flow_log_more_than_90_days" + ], + "Attributes": [ + { + "Title": "Network Security Group Flow Log retention period is 'greater than 90 days'", + "Section": "3. Logging and Monitoring", + "SubSection": "3.2 Retention", + "AttributeDescription": "Enable Network Security Group (NSG) Flow Logs and configure the retention period to at least 90 days to capture and store IP traffic data for security monitoring and analysis.", + "AdditionalInformation": "NSG Flow Logs provide visibility into network traffic, helping detect anomalies, unauthorized access, and potential security breaches. Retaining logs for at least 90 days ensures that historical data is available for incident investigation, compliance, and forensic analysis, strengthening overall network security monitoring.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.2.2", + "Description": "Ensure server parameter 'logfiles.retention_days' is greater than 3 days for PostgreSQL flexible server", + "Checks": [ + "postgresql_flexible_server_log_retention_days_greater_3" + ], + "Attributes": [ + { + "Title": "logfiles.retention_days' is greater than 3 days for PostgreSQL flexible server", + "Section": "3. Logging and Monitoring", + "SubSection": "3.2 Retention", + "AttributeDescription": "Ensure that logfiles.retention_days on PostgreSQL flexible servers is set to an appropriate value to maintain access to historical logs for monitoring and troubleshooting.", + "AdditionalInformation": "Setting an appropriate log retention period ensures that query and error logs are available for diagnosing configuration issues, troubleshooting errors, and optimizing performance. Retaining logs for a sufficient duration supports security analysis, compliance requirements, and operational debugging while preventing unnecessary storage consumption.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.2.3", + "Description": "Ensure that a 'Diagnostic Setting' exists for Subscription Activity Logs", + "Checks": [ + "monitor_diagnostic_settings_exists" + ], + "Attributes": [ + { + "Title": "Diagnostic Setting' exists for Subscription Activity Logs", + "Section": "3. Logging and Monitoring", + "SubSection": "3.2 Retention", + "AttributeDescription": "Enable Diagnostic Settings to export activity logs for all appropriate resources within a subscription, ensuring long-term visibility into security and operational events.", + "AdditionalInformation": "By default, logs are retained for only 90 days. Configuring diagnostic settings allows logs to be exported and stored for extended periods, enabling security analysis, compliance monitoring, and forensic investigations within an Azure subscription.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.1", + "Description": "Ensure that 'Auditing' is set to 'On' ", + "Checks": [ + "sqlserver_auditing_enabled" + ], + "Attributes": [ + { + "Title": "Auditing' is set to 'On'", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Enable auditing on Azure SQL Servers to track and log database events for security and compliance purposes.", + "AdditionalInformation": "Auditing at the server level ensures that all existing and newly created databases inherit auditing policies, providing consistent monitoring across the SQL environment. It does not override database-level auditing policies but complements them. Audit logs are stored in Azure Storage, helping organizations maintain regulatory compliance, monitor database activity, and detect anomalies that may indicate security threats or operational concerns.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.10", + "Description": "Ensure that Activity Log Alert exists for Delete SQL Server Firewall Rule", + "Checks": [ + "monitor_alert_delete_sqlserver_fr" + ], + "Attributes": [ + { + "Title": "Activity Log Alert exists for Delete SQL Server Firewall Rule", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Create an Activity Log Alert for the Delete SQL Server Firewall Rule event to monitor and track firewall rule removals in SQL Server.", + "AdditionalInformation": "Monitoring firewall rule deletions helps detect unauthorized or accidental changes that could expose the database to security risks. Timely alerts ensure quick detection and response to prevent unauthorized network access and maintain a secure SQL environment.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.11", + "Description": "Ensure that Activity Log Alert exists for Create or Update Public IP Address rule", + "Checks": [ + "monitor_alert_create_update_public_ip_address_rule" + ], + "Attributes": [ + { + "Title": "Activity Log Alert exists for Create or Update Public IP Address rule", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Create an Activity Log Alert for the Create or Update Public IP Address event to monitor changes in public IP configurations.", + "AdditionalInformation": "Tracking public IP address modifications provides visibility into network access changes, helping detect unauthorized or misconfigured public exposure. Timely alerts enable faster detection and response to potential security risks, ensuring a controlled and secure network environment.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "3.3.12", + "Description": "Ensure that Activity Log Alert exists for Delete Public IP Address rule", + "Checks": [ + "monitor_alert_delete_public_ip_address_rule" + ], + "Attributes": [ + { + "Title": "Activity Log Alert exists for Delete Public IP Address rule", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Create an Activity Log Alert for the Delete Public IP Address event to monitor and track the removal of public IP addresses.", + "AdditionalInformation": "Monitoring public IP deletions helps detect unauthorized or accidental changes that could impact network accessibility or security. Timely alerts enable quick investigation and response, ensuring that critical network configurations remain intact and secure.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.3.13", + "Description": "Ensure Application Insights are Configured", + "Checks": [ + "appinsights_ensure_is_configured" + ], + "Attributes": [ + { + "Title": "Application Insights are Configured", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Application Insights in Azure serves as an Application Performance Monitoring (APM) solution, providing valuable insights into application performance, telemetry data, and trace logs. It helps organizations monitor application health and troubleshoot incidents efficiently.", + "AdditionalInformation": "Enabling Application Insights enhances security monitoring and performance optimization by collecting metrics, telemetry, and trace logs. These logs aid in proactive performance tuning to reduce costs and support incident response by helping identify the root cause of potential security or operational issues. Integrating Application Insights into a broader logging and monitoring strategy strengthens an organization’s overall observability and security posture.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.14", + "Description": "Ensure that Network Watcher is 'Enabled' for Azure Regions that are in use", + "Checks": [ + "network_watcher_enabled" + ], + "Attributes": [ + { + "Title": "Network Watcher 'Enabled' for used Regions", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Enable Network Watcher for all Azure regions within your subscription to monitor and diagnose network activity.", + "AdditionalInformation": "Network Watcher provides network diagnostic and visualization tools that help organizations analyze traffic, troubleshoot connectivity issues, and detect anomalies. Enabling it enhances network visibility, security monitoring, and operational insights across Azure environments.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.15", + "Description": "Ensure that Endpoint Protection for all Virtual Machines is installed", + "Checks": [ + "defender_assessments_vm_endpoint_protection_installed" + ], + "Attributes": [ + { + "Title": "Endpoint Protection for all Virtual Machines is installed", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Ensure endpoint protection is installed on all Azure Virtual Machines (VMs) to provide real-time security monitoring and threat detection.", + "AdditionalInformation": "Endpoint protection helps detect and remove malware, viruses, and other security threats, protecting VMs from compromise and unauthorized access. It also provides configurable alerts for suspicious activity, enhancing security monitoring and incident response across Azure environments.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.16", + "Description": "Ensure that Microsoft Defender Recommendation for 'Apply system updates' status is 'Completed'", + "Checks": [ + "defender_ensure_system_updates_are_applied" + ], + "Attributes": [ + { + "Title": "Defender Recommendation for 'Apply system updates' status is 'Completed'", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Ensure that all Windows and Linux Virtual Machines (VMs) have the latest OS patches and security updates applied to mitigate vulnerabilities and improve system stability.", + "AdditionalInformation": "Keeping VMs updated helps address security vulnerabilities, bug fixes, and stability improvements. Microsoft Defender for Cloud continuously checks for missing critical and security updates using Windows Update, WSUS, or Linux package managers. Applying recommended updates reduces the risk of exploits, malware, and performance issues, ensuring a secure and resilient cloud environment.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.3.17", + "Description": "Ensure that Microsoft Cloud Security Benchmark policies are not set to 'Disabled'", + "Checks": [ + "policy_ensure_asc_enforcement_enabled" + ], + "Attributes": [ + { + "Title": "Microsoft Cloud Security Benchmark policies are not set to 'Disabled'", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Ensure that all Microsoft Cloud Security Benchmark (MCSB) policies are enabled to effectively evaluate resource configurations against best practice security recommendations.", + "AdditionalInformation": "The MCSB Policy Initiative enforces security best practices and helps ensure compliance with organizational and regulatory requirements. If a policy’s Effect is set to Disabled, it will not be evaluated, potentially preventing administrators from detecting security misconfigurations. Keeping all MCSB policies enabled allows Microsoft Defender for Cloud to assess relevant resources and provide actionable security insights to strengthen cloud security.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "3.3.18", + "Description": "Ensure That 'All users with the following roles' is set to 'Owner'", + "Checks": [ + "defender_ensure_notify_emails_to_owners" + ], + "Attributes": [ + { + "Title": "All users with the following roles' is set to 'Owner'", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Ensure that security alert emails are enabled for subscription owners to receive notifications about potential security threats and vulnerabilities.", + "AdditionalInformation": "Enabling security alert emails ensures that subscription owners are promptly informed of security incidents, threats, or misconfigurations detected by Microsoft Defender for Cloud. Timely notifications allow administrators to take immediate action, mitigate risks, and maintain a strong security posture within the Azure environment.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.3.19", + "Description": "Ensure 'Additional email addresses' is Configured with a Security Contact Email", + "Checks": [ + "defender_additional_email_configured_with_a_security_contact" + ], + "Attributes": [ + { + "Title": "Additional email addresses' is Configured with a Security Contact Email", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Configure Microsoft Defender for Cloud to send high-severity security alerts to a designated security contact email in addition to the subscription owner.", + "AdditionalInformation": "By default, Microsoft Defender for Cloud notifies only subscription owners of critical security alerts. Adding a security contact email ensures that the security team is promptly informed of potential threats, allowing for faster response and risk mitigation to maintain a secure Azure environment.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.3.2", + "Description": "Ensure Diagnostic Setting captures appropriate categories", + "Checks": [ + "monitor_diagnostic_setting_with_appropriate_categories" + ], + "Attributes": [ + { + "Title": "Diagnostic Setting captures appropriate categories", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Ensure that Diagnostic Settings are configured to log relevant control and management plane activities for enhanced visibility and security monitoring. (Note: A Diagnostic Setting must exist for this configuration to be available.)", + "AdditionalInformation": "Diagnostic settings determine how logs are exported and stored. Capturing logs from the control and management plane enables proper alerting, monitoring, and analysis of administrative actions, helping to detect unauthorized changes and security threats.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.20", + "Description": "Ensure That 'Notify about alerts with the following severity' is Set to 'High'", + "Checks": [ + "defender_ensure_notify_alerts_severity_is_high" + ], + "Attributes": [ + { + "Title": "Notify about alerts with the following severity' is Set to 'High'", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Enable security alert emails to notify the subscription owner or designated security contacts about potential security threats.", + "AdditionalInformation": "Ensuring security alerts are sent to the appropriate personnel allows for timely detection and response to security incidents. This helps mitigate risks by ensuring that critical threats and vulnerabilities are addressed promptly, improving the overall security posture of the Azure environment.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.3.21", + "Description": "Ensure That Microsoft Defender for DNS Is Set To 'On'", + "Checks": [ + "defender_ensure_defender_for_dns_is_on" + ], + "Attributes": [ + { + "Title": "Defender for DNS Is Set To 'On'", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Enable Microsoft Defender for DNS to monitor and scan outgoing DNS traffic within a subscription for potential security threats. (Note: As of August 1, 2023, new subscribers receive DNS threat alerts as part of Defender for Servers P2.)", + "AdditionalInformation": "Defender for DNS analyzes DNS queries against a dynamic threat intelligence list to detect potential malicious activity, compromised services, or security breaches. Monitoring DNS lookups helps identify and prevent threats such as data exfiltration, command and control (C2) communications, and phishing attacks, improving overall network security.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.3", + "Description": "Ensure that Activity Log Alert exists for Create Policy Assignment", + "Checks": [ + "monitor_alert_create_policy_assignment" + ], + "Attributes": [ + { + "Title": "Activity Log Alert exists for Create Policy Assignment", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Create an activity log alert for the Create Policy Assignment event to track changes in Azure Policy assignments.", + "AdditionalInformation": "Monitoring policy assignment events helps detect unauthorized or unintended changes in Azure policies, providing greater visibility and reducing the time required to identify and respond to policy modifications.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.4", + "Description": "Ensure that Activity Log Alert exists for Delete Policy Assignment", + "Checks": [ + "monitor_alert_delete_policy_assignment" + ], + "Attributes": [ + { + "Title": "Activity Log Alert exists for Delete Policy Assignment", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Create an activity log alert for the Delete Policy Assignment event to monitor and track policy removal activities in Azure Policy assignments.", + "AdditionalInformation": "Monitoring policy deletions helps detect unauthorized or unintended changes, ensuring policy integrity and reducing the time required to identify and respond to security or compliance violations.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.5", + "Description": "Ensure that Activity Log Alert exists for Create or Update Network Security Group", + "Checks": [ + "monitor_alert_create_update_nsg" + ], + "Attributes": [ + { + "Title": "Activity Log Alert exists for Create or Update Network Security Group", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Create an Activity Log Alert for the Create or Update Network Security Group (NSG) event to track changes in network security configurations.", + "AdditionalInformation": "Monitoring NSG creation and updates provides visibility into network access changes, helping to detect unauthorized modifications and identify potential security risks in a timely manner.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.6", + "Description": "Ensure that Activity Log Alert exists for Delete Network Security Group", + "Checks": [ + "monitor_alert_delete_nsg" + ], + "Attributes": [ + { + "Title": "Activity Log Alert exists for Delete Network Security Group", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Create an Activity Log Alert for the Delete Network Security Group (NSG) event to monitor and track network security group removals.", + "AdditionalInformation": "Monitoring NSG deletions provides visibility into network access changes, helping to detect unauthorized modifications and identify potential security threats before they impact the environment.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.7", + "Description": "Ensure that Activity Log Alert exists for Create or Update Security Solution", + "Checks": [ + "monitor_alert_create_update_security_solution" + ], + "Attributes": [ + { + "Title": "Activity Log Alert exists for Create or Update Security Solution", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Create an Activity Log Alert for the Create or Update Security Solution event to track modifications to security solutions in your environment.", + "AdditionalInformation": "Monitoring security solution changes provides visibility into updates, additions, or modifications to active security configurations. This helps detect unauthorized changes or suspicious activity and ensures that security controls remain properly configured.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.3.8", + "Description": "Ensure that Activity Log Alert exists for Delete Security Solution", + "Checks": [ + "monitor_alert_delete_security_solution" + ], + "Attributes": [ + { + "Title": "Activity Log Alert exists for Delete Security Solution", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Create an Activity Log Alert for the Delete Security Solution event to monitor and track the removal of security solutions in your environment.", + "AdditionalInformation": "Monitoring security solution deletions helps detect unauthorized removals or suspicious activity, ensuring that critical security controls are not accidentally or maliciously disabled. This improves security visibility and helps maintain a strong security posture.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.3.9", + "Description": "Ensure that Activity Log Alert exists for Create or Update SQL Server Firewall Rule", + "Checks": [ + "monitor_alert_create_update_sqlserver_fr" + ], + "Attributes": [ + { + "Title": "Activity Log Alert exists for Create or Update SQL Server Firewall Rule", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Create an Activity Log Alert for the Create or Update SQL Server Firewall Rule event to track changes in SQL Server firewall configurations.", + "AdditionalInformation": "Monitoring firewall rule modifications provides visibility into network access changes, helping detect unauthorized updates that could expose the database to security risks. Timely alerts can reduce the time needed to identify and respond to suspicious activity, ensuring a secure SQL environment.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "4.1.1", + "Description": "Ensure server parameter 'require_secure_transport' is set to 'ON' for PostgreSQL flexible server", + "Checks": [ + "postgresql_flexible_server_enforce_ssl_enabled" + ], + "Attributes": [ + { + "Title": "require_secure_transport' is set to 'ON' for PostgreSQL flexible server", + "Section": "4. Encryption", + "SubSection": "4.1 In-Transit", + "AttributeDescription": "Enable require_secure_transport on PostgreSQL flexible servers to enforce SSL connections between the database server and client applications, ensuring encrypted communication.", + "AdditionalInformation": "Requiring SSL encryption helps protect data in transit from man-in-the-middle attacks by securing the connection between the database server and client applications. Enforcing secure transport prevents unauthorized access and strengthens data integrity and confidentiality.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "4.1.2", + "Description": "Ensure server parameter 'require_secure_transport' is set to 'ON' for MySQL flexible server", + "Checks": [ + "postgresql_flexible_server_enforce_ssl_enabled" + ], + "Attributes": [ + { + "Title": "require_secure_transport' is set to 'ON' for MySQL flexible server", + "Section": "4. Encryption", + "SubSection": "4.1 In-Transit", + "AttributeDescription": "Enable require_secure_transport on MySQL flexible servers to enforce SSL encryption between the database server and client applications, ensuring secure communication.", + "AdditionalInformation": "Requiring SSL connectivity protects data in transit from man-in-the-middle attacks by encrypting communication between client applications and the database server. Enforcing secure transport helps prevent unauthorized access and data interception, strengthening the overall security posture of the database.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "4.1.3", + "Description": "Ensure the 'Minimum TLS version' for storage accounts is set to 'Version 1.2'", + "Checks": [ + "storage_ensure_minimum_tls_version_12" + ], + "Attributes": [ + { + "Title": "Minimum TLS version' for storage accounts is set to 'Version 1.2'", + "Section": "4. Encryption", + "SubSection": "4.1 In-Transit", + "AttributeDescription": "Ensure that the minimum TLS version for Azure Storage is set to TLS 1.2 or higher to mitigate security vulnerabilities associated with older TLS versions.", + "AdditionalInformation": "TLS 1.0 is outdated and has known security vulnerabilities that can expose data in transit to attacks and interception. Upgrading to TLS 1.2 or later enhances encryption security, ensuring secure communication between clients and Azure Storage while reducing the risk of data compromise.", + "LevelOfRisk": 2 + } + ] + }, + { + "Id": "4.1.4", + "Description": "Ensure 'HTTPS Only' is set to `On`", + "Checks": [ + "app_ensure_http_is_redirected_to_https" + ], + "Attributes": [ + { + "Title": "`HTTPS Only' is set to `On`", + "Section": "4. Encryption", + "SubSection": "4.1 In-Transit", + "AttributeDescription": "Configure Azure App Service to enforce HTTPS-only traffic, ensuring that all HTTP requests are automatically redirected to HTTPS for secure communication.", + "AdditionalInformation": "Enforcing HTTPS protects data in transit by using TLS/SSL encryption, preventing man-in-the-middle attacks and ensuring secure authentication. Redirecting non-secure HTTP traffic to HTTPS enhances the confidentiality and integrity of application communications, reducing exposure to security vulnerabilities.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "4.1.5", + "Description": "Ensure Web App is using the latest version of TLS encryption", + "Checks": [ + "app_minimum_tls_version_12" + ], + "Attributes": [ + { + "Title": "Web App is using the latest version of TLS encryption", + "Section": "4. Encryption", + "SubSection": "4.1 In-Transit", + "AttributeDescription": "Ensure that Azure App Service is configured to use TLS 1.2 or higher to secure data transmission and align with industry security standards.", + "AdditionalInformation": "TLS 1.0 and 1.1 are outdated protocols with known vulnerabilities that expose web applications to security threats, including data interception and man-in-the-middle attacks. TLS 1.2 is the recommended encryption standard by industry frameworks such as PCI DSS, providing stronger encryption and improved security for web app connections.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "4.1.6", + "Description": "Ensure that 'HTTP20enabled' is set to 'true'", + "Checks": [ + "app_ensure_using_http20" + ], + "Attributes": [ + { + "Title": "HTTP20enabled' is set to 'true'", + "Section": "4. Encryption", + "SubSection": "4.1 In-Transit", + "AttributeDescription": "Ensure that Azure App Service is configured to use the latest supported HTTP version to benefit from security improvements, performance enhancements, and new functionalities.", + "AdditionalInformation": "Newer HTTP versions provide security enhancements, performance optimizations, and better resource management. HTTP/2, for example, improves efficiency by addressing issues such as head-of-line blocking, header compression, and request prioritization. Keeping apps updated to the latest HTTP version ensures they leverage modern security protocols and enhanced data transmission capabilities while maintaining compatibility and performance standards.", + "LevelOfRisk": 2 + } + ] + }, + { + "Id": "4.2.1", + "Description": "Ensure Storage for Critical Data are Encrypted with Customer Managed Keys (CMK)", + "Checks": [ + "storage_ensure_encryption_with_customer_managed_keys" + ], + "Attributes": [ + { + "Title": "Storage for Critical Data are Encrypted CMK", + "Section": "4. Encryption", + "SubSection": "4.2 At-Rest", + "AttributeDescription": "Enable encryption at rest using Customer Managed Keys (CMK) instead of Microsoft Managed Keys to maintain greater control over sensitive data encryption in Azure Storage accounts.", + "AdditionalInformation": "By default, Azure encrypts all storage resources (blobs, disks, files, queues, and tables) using Microsoft Managed Keys. However, using Customer Managed Keys (CMK) allows organizations to control, manage, and rotate their encryption keys through Azure Key Vault, ensuring compliance with security policies. CMKs also support automatic key version updates for enhanced security. Since this recommendation applies specifically to storage accounts holding critical data, its assessment remains manual rather than automated.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "4.2.2", + "Description": "Ensure SQL server's Transparent Data Encryption (TDE) protector is encrypted with Customer-managed key", + "Checks": [ + "sqlserver_tde_encrypted_with_cmk" + ], + "Attributes": [ + { + "Title": "SQL server's TDE protector is encrypted with CMK", + "Section": "4. Encryption", + "SubSection": "4.2 At-Rest", + "AttributeDescription": "Enable Transparent Data Encryption (TDE) with Customer-Managed Keys (CMK) to enhance control, security, and separation of duties over the TDE Protector. TDE encrypts data at rest using a database encryption key (DEK). Traditionally, DEKs were protected by Azure SQL Service-managed certificates, but with Customer-Managed Key support, the DEK can now be secured using an asymmetric key stored in Azure Key Vault. Azure Key Vault provides centralized key management, FIPS 140-2 Level 2 validated HSMs, and additional security through key and data separation. Based on business needs and data sensitivity, organizations should use Customer-Managed Keys for TDE encryption.", + "AdditionalInformation": "Using Customer-Managed Keys for TDE gives organizations full control over encryption keys, including who can access them and when. Azure Key Vault serves as a secure external key management system, ensuring that TDE encryption keys remain protected from unauthorized access. When configured, the asymmetric key is set at the server level and inherited by all databases under that server, providing consistent encryption management across the environment.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "4.2.3", + "Description": "Ensure that 'Data encryption' is set to 'On' on a SQL Database", + "Checks": [ + "sqlserver_tde_encryption_enabled" + ], + "Attributes": [ + { + "Title": "Data encryption' is set to 'On' on a SQL Database", + "Section": "4. Encryption", + "SubSection": "4.2 At-Rest", + "AttributeDescription": "Enable Transparent Data Encryption (TDE) on all Azure SQL Servers to ensure real-time encryption and decryption of databases, backups, and transaction logs at rest. TDE operates seamlessly without requiring modifications to applications.", + "AdditionalInformation": "TDE helps protect Azure SQL Databases from unauthorized access and malicious activity by encrypting data at rest. This ensures that database files, backups, and logs remain secure, reducing the risk of data breaches while maintaining operational transparency.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "4.2.4", + "Description": "Ensure the storage account containing the container with activity logs is encrypted with Customer Managed Key (CMK)", + "Checks": [ + "monitor_storage_account_with_activity_logs_cmk_encrypted" + ], + "Attributes": [ + { + "Title": "Storage account with logs encrypted with CMK", + "Section": "4. Encryption", + "SubSection": "4.2 At-Rest", + "AttributeDescription": "Configure storage accounts used for activity log exports to use Customer Managed Keys (CMK) for enhanced security and access control.", + "AdditionalInformation": "Using CMKs for log storage provides additional confidentiality controls, ensuring that only users with read access to the storage account and explicit decrypt permissions can access the logs. This enhances data security by restricting unauthorized access and strengthening compliance with encryption and access management policies.", + "LevelOfRisk": 3 + } + ] + } + ] +} diff --git a/prowler/compliance/gcp/prowler_threatscore_gcp.json b/prowler/compliance/gcp/prowler_threatscore_gcp.json new file mode 100644 index 0000000000..2ccb7e7add --- /dev/null +++ b/prowler/compliance/gcp/prowler_threatscore_gcp.json @@ -0,0 +1,977 @@ +{ + "Framework": "ProwlerThreatScore", + "Version": "1.0", + "Provider": "GCP", + "Description": "Prowler ThreatScore Compliance Framework for GCP ensures that the GCP project is compliant taking into account four main pillars: Identity and Access Management, Attack Surface, Forensic Readiness and Encryption", + "Requirements": [ + { + "Id": "1.1.1", + "Description": "Ensure User-Managed/External Keys for Service Accounts Are Rotated Every 90 Days or Fewer", + "Checks": [ + "iam_sa_user_managed_key_rotate_90_days" + ], + "Attributes": [ + { + "Title": "User-Managed/External Keys for Service Accounts Are Rotated Every 90 Days or Fewer", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "Service account keys consist of a key ID (private_key_id) and a private key, which are used to authenticate programmatic requests to Google Cloud services. It is recommended to regularly rotate service account keys to enhance security and reduce the risk of unauthorized access.", + "AdditionalInformation": "Regularly rotating service account keys minimizes the risk of a compromised, lost, or stolen key being used to access cloud resources. Google-managed keys are automatically rotated daily for internal authentication, ensuring strong security. For user-managed (external) keys, users are responsible for key security, storage, and rotation. Since Google does not retain private keys once generated, proper key management practices must be followed. Google Cloud allows up to 10 external keys per service account, making it easier to rotate them without disruption. Implementing regular key rotation ensures that old keys are not left active, reducing the potential attack surface.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.1.2", + "Description": "Ensure API Keys Only Exist for Active Services", + "Checks": [ + "apikeys_key_exists" + ], + "Attributes": [ + { + "Title": "API Keys Only Exist for Active Services", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "API keys should only be used when no other authentication method is available, as they pose significant security risks. Unused API keys with active permissions may still exist within a project, potentially exposing resources to unauthorized access. It is recommended to use standard authentication flows such as OAuth 2.0 or service account authentication instead.", + "AdditionalInformation": "API keys are inherently insecure because they: Are simple encrypted strings that can be easily exposed in browsers, client-side applications, or devices. Do not authenticate users or applications making API requests. Can be accidentally leaked in logs, repositories, or web traffic.To enhance security, API keys should be avoided when possible, and unused keys should be deleted to minimize the risk of unauthorized access.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.1.3", + "Description": "Ensure API Keys Are Rotated Every 90 Days", + "Checks": [ + "apikeys_key_rotated_in_90_days" + ], + "Attributes": [ + { + "Title": "API Keys Are Rotated Every 90 Days", + "Section": "1. IAM", + "SubSection": "1.1 Authentication", + "AttributeDescription": "API keys should only be used when no other authentication method is available. If API keys are in use, it is recommended to rotate them every 90 days to minimize security risks.", + "AdditionalInformation": "API keys are inherently insecure because: They are simple encrypted strings that can be easily exposed. They do not authenticate users or applications making API requests. They are often accessible to clients, increasing the risk of theft and misuse. Unlike credentials with expiration policies, stolen API keys remain valid indefinitely unless revoked or regenerated. Regularly rotating API keys reduces the risk of unauthorized access by ensuring that compromised keys cannot be used for extended periods. To enhance security, API keys should be rotated every 90 days or as part of a proactive security policy.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.2.1", + "Description": "Ensure That There Are Only GCP-Managed Service Account Keys for Each Service Account", + "Checks": [ + "iam_sa_no_user_managed_keysiam_sa_no_user_managed_keys" + ], + "Attributes": [ + { + "Title": "Only GCP-Managed Service Account Keys for Each Service Account", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "Service accounts should not use user-managed keys, as they introduce security risks and require manual management. Instead, use Google Cloud-managed keys, which are automatically rotated and secured by Google.", + "AdditionalInformation": "User-managed keys are downloadable and manually managed, making them vulnerable to leaks, mismanagement, and unauthorized access. In contrast, GCP-managed keys are non-downloadable, automatically rotated weekly, and securely handled by Google Cloud services like App Engine and Compute Engine. Managing user-generated keys requires key storage, distribution, rotation, revocation, and protectionall of which introduce potential security gaps. Common risks include keys being exposed in source code repositories, left in unsecured locations, or unintentionally shared. To minimize security risks, it is recommended to disable user-managed service account keys and rely on GCP-managed keys instead.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.2.2", + "Description": "Ensure That Service Account Has No Admin Privileges", + "Checks": [ + "iam_sa_no_administrative_privileges" + ], + "Attributes": [ + { + "Title": "SA Has No Admin Privileges", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "A service account is a special Google account assigned to an application or virtual machine (VM) rather than an individual user. It is used to authenticate API requests on behalf of the application. Service accounts should not be granted admin privileges to minimize security risks.", + "AdditionalInformation": "Service accounts control resource access based on their assigned roles. Granting admin privileges to a service account allows full control over applications or VMs, enabling actions like deletion, updates, and configuration changes without user intervention. This increases the risk of misconfigurations, privilege escalation, or potential security breaches. To follow the principle of least privilege, it is recommended to restrict admin access for service accounts and assign only the necessary permissions.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.2.3", + "Description": "Ensure That Cloud KMS Cryptokeys Are Not Anonymously or Publicly Accessible", + "Checks": [ + "kms_key_not_publicly_accessible" + ], + "Attributes": [ + { + "Title": "Cloud KMS Cryptokeys Are Not Anonymously or Publicly Accessible", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "The IAM policy on Cloud KMS cryptographic keys should not allow anonymous (allUsers) or public (allAuthenticatedUsers) access to prevent unauthorized key usage.", + "AdditionalInformation": "Granting permissions to allUsers or allAuthenticatedUsers allows anyone to access the cryptographic keys, which can lead to data exposure, unauthorized encryption/decryption operations, or potential key compromise. This is particularly critical if sensitive data is protected using these keys. To maintain data security and compliance, ensure that Cloud KMS cryptographic keys are only accessible to authorized users, groups, or service accounts and do not have public or anonymous access permissions.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.2.4", + "Description": "Ensure KMS Encryption Keys Are Rotated Within a Period of 90 Days", + "Checks": [ + "kms_key_rotation_enabled" + ], + "Attributes": [ + { + "Title": "KMS Encryption Keys Are Rotated Within a Period of 90 Days", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "Google Cloud Key Management Service (KMS) organizes cryptographic keys in a hierarchical structure to facilitate secure and efficient access control. Keys should be configured with a defined rotation schedule to ensure their cryptographic strength is maintained over time.", + "AdditionalInformation": "Key rotation ensures that new key versions are automatically generated at regular intervals, reducing the risk of key compromise and unauthorized access. The key material (actual encryption bits) changes over time, even though the keys logical identity remains the same. Since cryptographic keys protect sensitive data, setting a specific rotation period ensures that encrypted data remains secure, minimizes the impact of a potential key leak, and aligns with best security practices.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.2.5", + "Description": "Ensure That Separation of Duties Is Enforced While Assigning KMS Related Roles to Users", + "Checks": [ + "iam_role_kms_enforce_separation_of_duties" + ], + "Attributes": [ + { + "Title": "Separation of Duties Is Enforced While Assigning KMS Related Roles to Users", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "The principle of Separation of Duties should be enforced when assigning Google Cloud Key Management Service (KMS) roles to users. This prevents excessive privileges and reduces security risks.", + "AdditionalInformation": "The Cloud KMS Admin role grants the ability to create, delete, and manage keys, while the Cloud KMS CryptoKey Encrypter/Decrypter, Encrypter, and Decrypter roles control encryption and decryption of data. Granting both administrative and cryptographic privileges to the same user violates the Separation of Duties principle, potentially allowing unauthorized access to sensitive data. To mitigate risks and prevent privilege escalation, no user should hold the Cloud KMS Admin role along with any of the CryptoKey Encrypter/Decrypter roles. Enforcing Separation of Duties helps ensure secure key management and aligns with security best practices.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.2.6", + "Description": "Ensure API Keys Are Restricted to Only APIs That Application Needs Access", + "Checks": [ + "apikeys_api_restrictions_configured" + ], + "Attributes": [ + { + "Title": "API Keys Are Restricted to Only APIs That Application Needs Access", + "Section": "1. IAM", + "SubSection": "1.2 Authorization", + "AttributeDescription": "API keys should only be used when no other authentication method is available, as they pose a higher security risk due to their public visibility. To minimize exposure, API keys should be restricted to access only the specific APIs required by an application.", + "AdditionalInformation": "API keys present several security risks, including: They are simple encrypted strings that can be easily exposed in client-side applications or browsers. They do not authenticate the user or application making API requests. They are often accessible to clients, making them susceptible to discovery and theft. Google recommends using standard authentication methods instead of API keys whenever possible. However, in limited scenarios where API keys are necessary (e.g., mobile applications using Google Cloud Translation API without a backend server), restricting API key access to only the required APIs helps enforce least privilege access and reduces attack surfaces.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "1.3.1", + "Description": "Ensure That IAM Users Are Not Assigned the Service Account User or Service Account Token Creator Roles at Project Level", + "Checks": [ + "iam_no_service_roles_at_project_level" + ], + "Attributes": [ + { + "Title": "IAM Users Are Not Assigned the SA User or SA Token Creator Roles at Project Level", + "Section": "1. IAM", + "SubSection": "1.3 Privilege Escalation Prevention", + "AttributeDescription": "It is recommended to assign the Service Account User (iam.serviceAccountUser) and Service Account Token Creator (iam.serviceAccountTokenCreator) roles to users at the service account level rather than granting them project-wide access.", + "AdditionalInformation": "Service accounts are identities used by applications and virtual machines (VMs) to interact with Google Cloud APIs. They also function as resources with IAM policies defining who can use them. Granting service account permissions at the project level allows users to access all service accounts within the project, including any created in the future. This increases the risk of privilege escalation, as users with Compute Instance Admin or App Engine Deployer roles could execute code as a service account, gaining access to additional resources. To enforce the principle of least privilege, users should be assigned service account roles at the specific service account level rather than at the project level. This ensures that each user has access only to the necessary service accounts while preventing unintended privilege escalation.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.3.2", + "Description": "Ensure That Separation of Duties Is Enforced While Assigning Service Account Related Roles to Users", + "Checks": [ + "iam_role_kms_enforce_separation_of_duties" + ], + "Attributes": [ + { + "Title": "Separation of Duties Is Enforced While Assigning Service Account Related Roles to Users", + "Section": "1. IAM", + "SubSection": "1.3 Privilege Escalation Prevention", + "AttributeDescription": "It is recommended to enforce the principle of Separation of Duties when assigning service account-related IAM roles to users to prevent excessive privileges and security risks.", + "AdditionalInformation": "The Service Account Admin role allows a user to create, delete, and manage service accounts, while the Service Account User role allows a user to assign service accounts to applications or compute instances. Granting both roles to the same user violates the Separation of Duties principle, as it would allow an individual to create and assign service accounts, potentially leading to unauthorized access or privilege escalation. To minimize security risks, no user should be assigned both Service Account Admin and Service Account User roles simultaneously. Enforcing Separation of Duties ensures better access control, reduces the risk of privilege abuse, and aligns with security best practices.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.3.3", + "Description": "Ensure That Cloud Audit Logging Is Configured Properly", + "Checks": [ + "iam_audit_logs_enabled" + ], + "Attributes": [ + { + "Title": "Cloud Audit Logging Is Configured Properly", + "Section": "1. IAM", + "SubSection": "1.3 Privilege Escalation Prevention", + "AttributeDescription": "Cloud Audit Logging should be configured to track all administrative activities and read/write access to user data. This ensures comprehensive visibility into who accessed or modified resources within a project, folder, or organization.", + "AdditionalInformation": "Cloud Audit Logging maintains two types of audit logs: 1. Admin Activity Logs Captures API calls and administrative actions that modify configurations or metadata. These logs are enabled by default and cannot be disabled. 2. Data Access Logs Tracks API calls that create, modify, or read user data. These logs are disabled by default and should be enabled for better monitoring. Data Access Logs provide three types of visibility: Admin Read Tracks metadata or configuration reads. Data Read Logs operations where user-provided data is accessed. Data Write Captures modifications to user-provided data.To ensure effective logging, it is recommended to: 1. Enable DATA_READ logs (for user activity tracking) and DATA_WRITE logs (to track modifications). 2. Apply audit logging to all supported services where Data Access logs are available. 3.Avoid exempting users from audit logs to maintain full tracking capabilities. Properly configuring Cloud Audit Logging helps strengthen security, detect unauthorized access, and ensure compliance with security policies.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.3.4", + "Description": "Ensure Log Metric Filter and Alerts Exist for Project Ownership Assignments/Changes", + "Checks": [ + "logging_log_metric_filter_and_alert_for_project_ownership_changes_enabled" + ], + "Attributes": [ + { + "Title": "Log Metric Filter and Alerts Exist for Project Ownership Assignments/Changes", + "Section": "1. IAM", + "SubSection": "1.3 Privilege Escalation Prevention", + "AttributeDescription": "In order to prevent unnecessary project ownership assignments to users or service accounts and mitigate potential misuse of projects and resources, all role assignments to roles/Owner should be monitored. Users or service accounts assigned the roles/Owner primitive role are considered project owners. The Owner role grants full control over the project, including: full viewer permissions on all GCP services, permissions to modify the state of all services, manage roles and permissions for the project and its resources, and set up billing for the project. Granting the Owner role allows the member to modify the IAM policy, which contains sensitive access control data. To minimize security risks, the Owner role should only be assigned when strictly necessary, and the number of users with this role should be kept to a minimum.", + "AdditionalInformation": "Project ownership has the highest level of privileges within a project, making it a high-risk role if misused. To reduce potential security risks, all project ownership assignments and changes should be monitored and alerted to security teams or relevant recipients. Critical events to monitor include: sending project ownership invitations, acceptance or rejection of ownership invites, assigning the roles/Owner role to a user or service account, and removing a user or service account from the roles/Owner role. Monitoring these activities helps prevent unauthorized access, enforces least privilege principles, and improves security auditing and compliance.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.3.5", + "Description": "Ensure That the Log Metric Filter and Alerts Exist for Audit Configuration Changes", + "Checks": [ + "logging_log_metric_filter_and_alert_for_audit_configuration_changes_enabled" + ], + "Attributes": [ + { + "Title": "Log Metric Filter and Alerts Exist for Audit Configuration Changes", + "Section": "1. IAM", + "SubSection": "1.3 Privilege Escalation Prevention", + "AttributeDescription": "Google Cloud Platform (GCP) services generate audit log entries in the Admin Activity and Data Access logs, providing visibility into who performed what action, where, and when within GCP projects. These logs capture key details such as the identity of the API caller, timestamp, source IP address, request parameters, and response data. Cloud audit logging records API calls made through the GCP Console, SDKs, command-line tools, and other GCP services, offering a comprehensive activity history for security monitoring and compliance.", + "AdditionalInformation": "Admin activity and data access logs play a critical role in security analysis, resource change tracking, and compliance auditing. Configuring metric filters and alerts for audit configuration changes ensures that audit logging remains in its recommended state, allowing organizations to detect and respond to unauthorized modifications while ensuring all project activities remain fully auditable at any time.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "1.3.6", + "Description": "Ensure That the Log Metric Filter and Alerts Exist for Custom Role Changes", + "Checks": [ + "logging_log_metric_filter_and_alert_for_custom_role_changes_enabled" + ], + "Attributes": [ + { + "Title": "Log Metric Filter and Alerts Exist for Custom Role Changes", + "Section": "1. IAM", + "SubSection": "1.3 Privilege Escalation Prevention", + "AttributeDescription": "It is recommended to set up a metric filter and alarm to track changes to Identity and Access Management (IAM) roles, including their creation, deletion, and updates. Google Cloud IAM provides predefined roles for granular access control but also allows organizations to create custom roles to meet specific needs.", + "AdditionalInformation": "IAM role modifications can impact security by granting excessive privileges if not properly managed. Monitoring role creation, deletion, and updates helps detect potential misconfigurations or over-privileged roles early, ensuring that only intended access permissions are assigned within the organization.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "2.1.1", + "Description": "Ensure That the Default Network Does Not Exist in a Project ", + "Checks": [ + "compute_network_default_in_use" + ], + "Attributes": [ + { + "Title": "Default Network Does Not Exist in a Project ", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "A project should not have a default network to prevent the use of preconfigured and potentially insecure network settings.", + "AdditionalInformation": "The default network automatically creates permissive firewall rules, including unrestricted internal traffic, SSH, RDP, and ICMP access, which increases the risk of unauthorized access. Additionally, it is an auto mode network, limiting flexibility in subnet configuration and restricting the use of Cloud VPN or VPC Network Peering. Organizations should create a custom network tailored to their security and networking needs and remove the default network to minimize exposure.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.1.2", + "Description": "Ensure Legacy Networks Do Not Exist for Older Projects", + "Checks": [ + "compute_network_not_legacy" + ], + "Attributes": [ + { + "Title": "Legacy Networks Do Not Exist for Older Projects", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "Projects should not have a legacy network configured to prevent the use of outdated and inflexible networking models. While new projects can no longer create legacy networks, older projects should be checked to ensure they are not still using them.", + "AdditionalInformation": "Legacy networks use a single global IPv4 prefix and a single gateway IP for the entire network, lacking subnetting capabilities. This design limits flexibility, prevents migration to auto or custom subnet networks, and can create performance bottlenecks or single points of failure for high-traffic workloads. Removing legacy networks and transitioning to modern networking models improves scalability, security, and resilience.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.1.4", + "Description": "Ensure That SSH Access Is Restricted From the Internet", + "Checks": [ + "compute_firewall_ssh_access_from_the_internet_allowed" + ], + "Attributes": [ + { + "Title": "SSH Access Is Restricted From the Internet", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "GCP Firewall Rules control ingress and egress traffic within a VPC Network. These rules define traffic conditions such as ports, protocols, and source/destination IPs. Firewall rules operate at the VPC level and cannot be shared across networks. Only IPv4 addresses are supported, and it is crucial to restrict generic (0.0.0.0/0) incoming traffic, particularly for SSH on Port 22, to prevent unauthorized access.", + "AdditionalInformation": "Firewall rules regulate traffic flow between instances and external networks. Allowing unrestricted inbound SSH access (0.0.0.0/0 on port 22) increases security risks by exposing instances to unauthorized access and brute-force attacks. To minimize threats, internet-facing access should be limited by specifying granular IP ranges and enforcing least privilege access.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.1.5", + "Description": "Ensure That RDP Access Is Restricted From the Internet", + "Checks": [ + "compute_firewall_rdp_access_from_the_internet_allowed" + ], + "Attributes": [ + { + "Title": "RDP Access Is Restricted From the Internet", + "Section": "2. Attack Surface", + "SubSection": "2.1 Network", + "AttributeDescription": "GCP Firewall Rules control incoming (ingress) and outgoing (egress) traffic within a VPC Network. Each rule specifies traffic conditions, including ports, protocols, and source/destination IPs. These rules operate at the VPC level, cannot be shared across networks, and support only IPv4 addresses. To enhance security, unrestricted RDP access (0.0.0.0/0 on port 3389) should be avoided to prevent unauthorized remote connections.", + "AdditionalInformation": "Firewall rules regulate traffic flow between instances and external networks. Allowing unrestricted RDP access from the Internet exposes virtual machines (VMs) to unauthorized access and brute-force attacks. To mitigate risks, internet-facing access should be restricted by enforcing least privilege access, defining specific IP ranges, and implementing secure remote access solutions such as Bastion hosts or VPNs.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.2.1", + "Description": "Ensure That Cloud Storage Bucket Is Not Anonymously or Publicly Accessible", + "Checks": [ + "cloudstorage_bucket_public_access" + ], + "Attributes": [ + { + "Title": "Cloud Storage Bucket Is Not Anonymously or Publicly Accessible", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "IAM policies on Cloud Storage buckets should not allow anonymous or public access to prevent unauthorized data exposure.", + "AdditionalInformation": "Granting public or anonymous access allows anyone to access the buckets contents, posing a security risk, especially if sensitive data is stored. Restricting access ensures that only authorized users can interact with the bucket, reducing the risk of data breaches.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.2.2", + "Description": "Ensure 'user Connections' Database Flag for Cloud Sql Sql Server Instance Is Set to a Non-limiting Value", + "Checks": [ + "cloudsql_instance_sqlserver_user_connections_flag" + ], + "Attributes": [ + { + "Title": "user Connections Database Flag for Cloud Sql Sql Server Instance Is Set to a Non-limiting Value", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Verify the user connection limits for Cloud SQL SQL Server instances to ensure they are not unnecessarily restricting the number of simultaneous connections.", + "AdditionalInformation": "The user connections setting controls the maximum number of concurrent user connections allowed on an SQL Server instance. By default, SQL Server dynamically adjusts the number of connections as needed, up to a maximum of 32,767. Setting an artificial limit may prevent new connections from being established, leading to potential data loss or service outages. It is recommended to review and adjust this setting as necessary to avoid disruptions.", + "LevelOfRisk": 2 + } + ] + }, + { + "Id": "2.2.3", + "Description": "Ensure 'remote access' database flag for Cloud SQL SQL Server instance is set to 'off'", + "Checks": [ + "cloudsql_instance_sqlserver_remote_access_flag" + ], + "Attributes": [ + { + "Title": "remote access database flag for Cloud SQL SQL Server instance is set to off", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Disable the remote access database flag for Cloud SQL SQL Server instances to prevent execution of stored procedures from remote servers.", + "AdditionalInformation": "The remote access option allows stored procedures to be executed from or on remote SQL Server instances. By default, this setting is enabled, which could be exploited for unauthorized query execution or Denial-of-Service (DoS) attacks by offloading processing to a target server. Disabling remote access enhances security by restricting stored procedure execution to the local server, reducing potential attack vectors. This recommendation applies to SQL Server database instances.", + "LevelOfRisk": 2 + } + ] + }, + { + "Id": "2.2.5", + "Description": "Ensure That Cloud SQL Database Instances Do Not Implicitly Whitelist All Public IP Addresses", + "Checks": [ + "cloudsql_instance_public_access" + ], + "Attributes": [ + { + "Title": "Cloud SQL Database Instances Do Not Implicitly Whitelist All Public IP Addresses", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Restrict database server access to only trusted networks and IP addresses, preventing connections from public IPs.", + "AdditionalInformation": "Allowing unrestricted access to a database server increases the risk of unauthorized access and attacks. To minimize the attack surface, only trusted and necessary IP addresses should be whitelisted. Authorized networks should not be set to 0.0.0.0/0, which permits connections from anywhere. This control applies specifically to instances with public IP addresses.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.2.6", + "Description": "Ensure That Cloud SQL Database Instances Do Not Have Public IPs", + "Checks": [ + "cloudsql_instance_public_access" + ], + "Attributes": [ + { + "Title": "Cloud SQL Database Instances Do Not Have Public IPs", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Configure Second Generation Cloud SQL instances to use private IPs instead of public IPs.", + "AdditionalInformation": "Using private IPs for Cloud SQL databases enhances security by reducing exposure to external threats. It also improves network performance and lowers latency by keeping traffic within the internal network, minimizing the attack surface of the database.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "2.2.7", + "Description": "Ensure That BigQuery Datasets Are Not Anonymously or Publicly Accessible", + "Checks": [ + "bigquery_dataset_public_access" + ], + "Attributes": [ + { + "Title": "BigQuery Datasets Are Not Anonymously or Publicly Accessible", + "Section": "2. Attack Surface", + "SubSection": "2.2 Storage", + "AttributeDescription": "Ensure that IAM policies on BigQuery datasets do not allow anonymous or public access.", + "AdditionalInformation": "Granting access to allUsers or allAuthenticatedUsers permits unrestricted access to the dataset, which can lead to unauthorized data exposure. To protect sensitive information, public or anonymous access should be strictly prohibited.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.3.3", + "Description": "Ensure That Instances Are Not Configured To Use the Default Service Account With Full Access to All Cloud APIs", + "Checks": [ + "compute_instance_default_service_account_in_use_with_full_api_access" + ], + "Attributes": [ + { + "Title": "Instances Are Not Configured To Use the Default Service Account With Full Access to All Cloud APIs", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "To enforce the principle of least privilege and prevent potential privilege escalation, instances should not be assigned the Compute Engine default service account with the scope Allow full access to all Cloud APIs.", + "AdditionalInformation": "Google Compute Engine provides a default service account for instances to access necessary cloud services. This default service account has the Project Editor role, granting broad permissions over most cloud services except billing. When assigned to an instance, it can operate in three modes: 1.Allow default access Grants minimal required permissions (recommended). 2.Allow full access to all Cloud APIs Grants excessive access to all cloud services (not recommended). 3.Set access for each API Allows administrators to specify required APIs (preferred for least privilege). Assigning an instance the Compute Engine default service account with full access to all APIs can expose cloud operations to unauthorized users based on IAM roles. To reduce security risks, instances should use custom service accounts with minimal required permissions.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "2.3.4", + "Description": "Ensure Block Project-Wide SSH Keys Is Enabled for VM Instances ", + "Checks": [ + "compute_instance_block_project_wide_ssh_keys_disabled" + ], + "Attributes": [ + { + "Title": "Block Project-Wide SSH Keys Is Enabled for VM Instances ", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Instances should use instance-specific SSH keys instead of project-wide SSH keys to enhance security and reduce the risk of unauthorized access.", + "AdditionalInformation": "Project-wide SSH keys are stored in Compute Project metadata and can be used to access all instances within a project. While this simplifies SSH key management, it also increases security risksif a project-wide SSH key is compromised, all instances in the project could be affected. Using instance-specific SSH keys provides better security by limiting access to individual instances, reducing the attack surface in case of key compromise.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.3.5", + "Description": "Ensure Enable Connecting to Serial Ports Is Not Enabled for VM Instance", + "Checks": [ + "compute_instance_serial_ports_in_use" + ], + "Attributes": [ + { + "Title": "Enable Connecting to Serial Ports Is Not Enabled for VM Instance", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "The interactive serial console allows direct access to a virtual machines serial ports, similar to using a terminal window. When enabled, it allows connections from any IP address, creating a potential security risk. It is recommended to disable interactive serial console support.", + "AdditionalInformation": "A virtual machine instance has four virtual serial ports, often used by the operating system, BIOS, or other system-level entities for input and output. The first serial port (serial port 1) is commonly referred to as the serial console. Unlike SSH, the interactive serial console does not support IP-based access restrictions, meaning anyone with the correct SSH key, username, project ID, zone, and instance name could gain access. This exposes the instance to unauthorized access. To mitigate this risk, interactive serial console support should be disabled unless absolutely necessary.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "2.3.6", + "Description": "Ensure That IP Forwarding Is Not Enabled on Instances", + "Checks": [ + "compute_instance_ip_forwarding_is_enabled" + ], + "Attributes": [ + { + "Title": "IP Forwarding Is Not Enabled on Instances", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Google Compute Engine instances should not forward data packets unless explicitly required for routing purposes. By default, an instance cannot forward packets unless the source IP matches the instances IP address. Similarly, GCP wont deliver packets if the destination IP does not match the instance. To prevent unauthorized data forwarding, it is recommended to disable IP forwarding.", + "AdditionalInformation": "When IP forwarding is enabled (canIpForward field), an instance can send and receive packets with non-matching source or destination IPs, effectively allowing it to act as a network router. This can lead to data loss, information disclosure, or unauthorized traffic routing. To maintain security and prevent misuse, IP forwarding should be disabled unless explicitly required for network routing configurations.", + "LevelOfRisk": 2 + } + ] + }, + { + "Id": "2.3.7", + "Description": "Ensure Compute Instances Are Launched With Shielded VM Enabled", + "Checks": [ + "compute_instance_shielded_vm_enabled" + ], + "Attributes": [ + { + "Title": "Compute Instances Are Launched With Shielded VM Enabled", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Shielded VMs are hardened virtual machines on Google Cloud Platform (GCP) designed to protect against rootkits, bootkits, and other low-level attacks. They ensure verifiable integrity using Secure Boot, virtual Trusted Platform Module (vTPM)-enabled Measured Boot, and integrity monitoring.", + "AdditionalInformation": "Shielded VMs use signed and verified firmware from Googles Certificate Authority to establish a root of trust. Secure Boot ensures only authentic software runs by verifying digital signatures, preventing unauthorized modifications. Integrity monitoring helps detect unexpected changes in the VMs boot process, while vTPM-enabled Measured Boot provides a baseline to compare against future boots. Enabling Shielded VMs enhances security by protecting against malware, unauthorized firmware changes, and persistent threats.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "2.3.8", + "Description": "Ensure That Compute Instances Do Not Have Public IP Addresses", + "Checks": [ + "compute_instance_public_ip" + ], + "Attributes": [ + { + "Title": "That Compute Instances Do Not Have Public IP Addresses", + "Section": "2. Attack Surface", + "SubSection": "2.3 Application", + "AttributeDescription": "Compute instances should not be assigned external IP addresses to minimize exposure to the internet and reduce security risks.", + "AdditionalInformation": "Public IP addresses increase the attack surface of Compute instances, making them more vulnerable to threats. Instead, instances should be placed behind load balancers or use private networking to control access and reduce the risk of unauthorized exposure.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "3.1.1", + "Description": "Ensure That Sinks Are Configured for All Log Entries", + "Checks": [ + "cloudstorage_bucket_log_retention_policy_lock" + ], + "Attributes": [ + { + "Title": "Sinks Are Configured for All Log Entries", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "It is recommended to create a log sink to export and store copies of all log entries. This enables log aggregation across multiple projects and allows integration with a Security Information and Event Management (SIEM) system for centralized monitoring.", + "AdditionalInformation": "Cloud Logging retains logs for a limited period. To ensure long-term storage and better security analysis, logs should be exported to a destination such as Cloud Storage, BigQuery, or Cloud Pub/Sub. A log sink allows you to: Aggregate logs from multiple projects, folders, or billing accounts. Extend log retention beyond Cloud Loggings default retention period. Send logs to a SIEM system for real-time monitoring and threat detection. To ensure all logs are captured and exported: 1.Create a sink without filters to capture all log entries. 2.Choose an appropriate destination (e.g., Cloud Storage for long-term storage, BigQuery for analysis, or Pub/Sub for real-time processing). 3.Apply logging at the organization level to cover all associated projects. Implementing log sinks enhances security visibility, forensic capabilities, and compliance adherence across cloud environments.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "3.1.2", + "Description": "Ensure That the Log Metric Filter and Alerts Exist for VPC Network Firewall Rule Changes", + "Checks": [ + "logging_log_metric_filter_and_alert_for_vpc_firewall_rule_changes_enabled" + ], + "Attributes": [ + { + "Title": "Log Metric Filter and Alerts Exist for VPC Network Firewall Rule Changes", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "It is recommended to configure a metric filter and alarm to monitor Virtual Private Cloud (VPC) Network Firewall rule changes. Tracking modifications to firewall rules helps ensure that unauthorized or unintended changes do not compromise network security.", + "AdditionalInformation": "Firewall rules control ingress and egress traffic within a VPC. Monitoring create or update events provides visibility into network access changes and helps quickly detect potential security threats or misconfigurations, reducing the risk of unauthorized access.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.1.3", + "Description": "Ensure That the Log Metric Filter and Alerts Exist for VPC Network Route Changes", + "Checks": [ + "logging_log_metric_filter_and_alert_for_vpc_network_route_changes_enabled" + ], + "Attributes": [ + { + "Title": "Log Metric Filter and Alerts Exist for VPC Network Route Changes", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "It is recommended to configure a metric filter and alarm to monitor Virtual Private Cloud (VPC) network route changes. Keeping track of modifications ensures that unauthorized or unintended changes do not disrupt expected network traffic flow.", + "AdditionalInformation": "GCP routes define how network traffic is directed between VM instances and external destinations. Monitoring route table changes helps ensure that traffic follows the intended path, preventing misconfigurations or malicious alterations that could lead to data exposure or connectivity issues.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.1.4", + "Description": "Ensure That the Log Metric Filter and Alerts Exist for VPC Network Changes", + "Checks": [ + "logging_log_metric_filter_and_alert_for_vpc_network_changes_enabled" + ], + "Attributes": [ + { + "Title": "Log Metric Filter and Alerts Exist for VPC Network Changes", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "It is recommended to configure a metric filter and alarm to monitor Virtual Private Cloud (VPC) network changes. This helps track modifications to VPC configurations and peer connections, ensuring that network traffic remains secure and follows the intended paths.", + "AdditionalInformation": "It is recommended to configure a metric filter and alarm to monitor Virtual Private Cloud (VPC) network changes. This helps track modifications to VPC configurations and peer connections, ensuring that network traffic remains secure and follows the intended paths.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "3.1.5", + "Description": "Ensure That the Log Metric Filter and Alerts Exist for Cloud Storage IAM Permission Changes", + "Checks": [ + "logging_log_metric_filter_and_alert_for_bucket_permission_changes_enabled" + ], + "Attributes": [ + { + "Title": "Log Metric Filter and Alerts Exist for Cloud Storage IAM Permission Changes", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "It is recommended to set up a metric filter and alarm to monitor Cloud Storage Bucket IAM changes. This ensures that any modifications to bucket permissions are tracked and reviewed in a timely manner.", + "AdditionalInformation": "Monitoring changes to Cloud Storage IAM policies helps detect and correct unauthorized access or overly permissive configurations. This reduces the risk of data exposure or breaches by ensuring that sensitive storage buckets and their contents remain properly secured.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.1.6", + "Description": "Ensure That the Log Metric Filter and Alerts Exist for SQL Instance Configuration Changes", + "Checks": [ + "logging_log_metric_filter_and_alert_for_sql_instance_configuration_changes_enabled" + ], + "Attributes": [ + { + "Title": "Log Metric Filter and Alerts Exist for SQL Instance Configuration Changes", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "It is recommended to configure a metric filter and alarm to track SQL instance configuration changes. This helps in detecting and addressing misconfigurations that may impact security, availability, and compliance.", + "AdditionalInformation": "Monitoring SQL instance configuration changes ensures that critical security settings remain properly configured. Misconfigurations, such as disabling auto backups, allowing untrusted networks, or modifying high availability settings, can lead to data loss, security vulnerabilities, or operational disruptions. Early detection of such changes helps maintain a secure and resilient SQL environment.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.1.7", + "Description": "Ensure Logging is enabled for HTTP(S) Load Balancer ", + "Checks": [ + "compute_loadbalancer_logging_enabled" + ], + "Attributes": [ + { + "Title": "Logging is enabled for HTTP(S) Load Balancer ", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "Enabling logging on an HTTPS Load Balancer captures all network traffic and its destination, providing visibility into requests made to your web applications.", + "AdditionalInformation": "Logging HTTPS network traffic helps monitor access patterns, troubleshoot issues, and enhance security by detecting suspicious activity or unauthorized access attempts.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.1.8", + "Description": "Ensure that VPC Flow Logs is Enabled for Every Subnet in a VPC Network", + "Checks": [ + "compute_subnet_flow_logs_enabled" + ], + "Attributes": [ + { + "Title": "VPC Flow Logs is Enabled for Every Subnet in a VPC Network", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "Flow Logs capture and record IP traffic to and from network interfaces within VPC subnets. These logs are stored in Stackdriver Logging, allowing users to analyze traffic patterns, detect anomalies, and optimize network performance. It is recommended to enable Flow Logs for all critical VPC subnets to enhance network visibility and security.", + "AdditionalInformation": "VPC Flow Logs provide detailed insights into inbound and outbound traffic for virtual machines (VMs), whether they communicate with other VMs, on-premises data centers, Google services, or external networks. Enabling Flow Logs supports: Network monitoring Traffic analysis and cost optimization Incident investigation and forensics Real-time security threat detection For effective monitoring, Flow Logs should be configured to capture all traffic, use granular logging intervals, avoid log filtering, and include metadata for detailed investigations. Note that subnets reserved for internal HTTP(S) load balancing do not support Flow Logs.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.1.9", + "Description": "Ensure That the Log_connections Database Flag for Cloud SQL PostgreSQL Instance Is Set to On", + "Checks": [ + "cloudsql_instance_postgres_log_connections_flag" + ], + "Attributes": [ + { + "Title": "Log_connections Database Flag for Cloud SQL PostgreSQL Instance Is Set to On", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "The log_connections setting should be enabled to log all attempted connections to the PostgreSQL server, including successful client authentication.", + "AdditionalInformation": "By default, PostgreSQL does not log connection attempts, making it harder to detect unauthorized access. Enabling log_connections provides visibility into all connection attempts, aiding in troubleshooting and identifying unusual or suspicious access patterns. This is particularly useful for security monitoring and incident response.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.1.10", + "Description": "Ensure That the Log_disconnections Database Flag for Cloud SQL PostgreSQL Instance Is Set to On", + "Checks": [ + "cloudsql_instance_postgres_log_disconnections_flag" + ], + "Attributes": [ + { + "Title": "Log_disconnections Database Flag for Cloud SQL PostgreSQL Instance Is Set to On", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "The log_disconnections setting should be enabled to log the end of each PostgreSQL session, including session duration.", + "AdditionalInformation": "By default, PostgreSQL does not log session termination details, making it difficult to track session activity. Enabling log_disconnections helps monitor session durations and detect unusual activity. Combined with log_connections, it provides a complete audit trail of user access, aiding in troubleshooting and security monitoring.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "3.1.11", + "Description": "Ensure Log_statement Database Flag for Cloud SQL PostgreSQL Instance Is Set Appropriately", + "Checks": [ + "cloudsql_instance_postgres_log_statement_flag" + ], + "Attributes": [ + { + "Title": "Log_statement Database Flag for Cloud SQL PostgreSQL Instance Is Set Appropriately", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "The log_statement setting in PostgreSQL determines which SQL statements are logged. Acceptable values include none, ddl, mod, and all. A recommended setting is ddl, which logs all data definition statements unless otherwise specified by the organizations logging policy.", + "AdditionalInformation": "Proper SQL statement logging is crucial for auditing and forensic analysis. If too many statements are logged, it can become difficult to extract relevant information; if too few are logged, critical details may be missing. Setting log_statement to an appropriate value, such as ddl, ensures a balance between comprehensive auditing and log manageability, aiding in database security and compliance.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.1.12", + "Description": "Ensure that the Log_min_messages Flag for a Cloud SQL PostgreSQL Instance is set at minimum to 'Warning'", + "Checks": [ + "cloudsql_instance_postgres_log_min_messages_flag" + ], + "Attributes": [ + { + "Title": "Log_min_messages Flag for a Cloud SQL PostgreSQL Instance is set at minimum to Warning", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "The log_min_messages setting in PostgreSQL defines the minimum severity level for messages to be logged as errors. Accepted values range from DEBUG5 (least severe) to PANIC (most severe). Best practice is to set this value to ERROR, ensuring that only critical issues are logged unless an organizations policy requires a different threshold.", + "AdditionalInformation": "Proper logging is essential for troubleshooting and forensic analysis. If log_min_messages is not configured correctly, important error messages may be missed or unnecessary logs may clutter records. Setting this parameter to ERROR helps maintain a balance between capturing relevant issues and avoiding excessive log noise, improving system monitoring and security.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.1.13", + "Description": "Ensure Log_min_error_statement Database Flag for Cloud SQL PostgreSQL Instance Is Set to Error or Stricter", + "Checks": [ + "cloudsql_instance_postgres_log_min_error_statement_flag" + ], + "Attributes": [ + { + "Title": "Log_min_error_statement Database Flag for Cloud SQL PostgreSQL Instance Is Set to Error or Stricter", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "The log_min_error_statement setting in PostgreSQL defines the minimum severity level for statements to be logged as errors. Valid values range from DEBUG5 (least severe) to PANIC (most severe). It is recommended to set this value to ERROR or stricter to ensure only relevant error statements are logged.", + "AdditionalInformation": "Proper logging aids in troubleshooting and forensic analysis. If log_min_error_statement is set too leniently, excessive log entries may make it difficult to identify actual errors. Conversely, if it is set too strictly, important errors may be missed. Setting this parameter to ERROR or higher ensures that significant issues are recorded while avoiding unnecessary log clutter.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.1.14", + "Description": "Ensure That the Log_min_duration_statement Database Flag for Cloud SQL PostgreSQL Instance Is Set to '-1' (Disabled) ", + "Checks": [ + "cloudsql_instance_postgres_log_min_duration_statement_flag" + ], + "Attributes": [ + { + "Title": "Log_min_duration_statement Database Flag for Cloud SQL PostgreSQL Instance Is Set to -1 (Disabled) ", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "The log_min_duration_statement setting in PostgreSQL determines the minimum execution time (in milliseconds) required for a statement to be logged. It is recommended to disable this setting by setting its value to -1.", + "AdditionalInformation": "Logging SQL statements may expose sensitive information, which could lead to security risks if recorded in logs. Disabling this setting ensures that confidential data is not inadvertently captured. This recommendation applies to PostgreSQL database instances.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "3.1.15", + "Description": "Ensure That 'cloudsql.enable_pgaudit' Database Flag for each Cloud Sql Postgresql Instance Is Set to 'on' For Centralized Logging", + "Checks": [ + "cloudsql_instance_postgres_enable_pgaudit_flag" + ], + "Attributes": [ + { + "Title": "cloudsql.enable_pgaudit Database Flag for each Cloud Sql Postgresql Instance Is Set to on For Centralized Logging", + "Section": "3. Logging and Monitoring", + "SubSection": "3.1 Logging", + "AttributeDescription": "Ensure that the cloudsql.enable_pgaudit database flag is set to on for Cloud SQL PostgreSQL instances to enable centralized logging and auditing.", + "AdditionalInformation": "Enabling the pgaudit extension provides detailed session and object-level logging, which helps organizations comply with security standards such as government, financial, and ISO regulations. This logging capability enhances threat detection by monitoring security events on the database instance. Additionally, enabling this flag allows logs to be sent to Google Logs Explorer for centralized access and monitoring. This recommendation applies specifically to PostgreSQL database instances.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "3.2.1", + "Description": "Ensure That Retention Policies on Cloud Storage Buckets Used for Exporting Logs Are Configured Using Bucket Lock", + "Checks": [ + "cloudstorage_bucket_log_retention_policy_lock" + ], + "Attributes": [ + { + "Title": "Retention Policies on Cloud Storage Buckets Used for Exporting Logs Are Configured Using Bucket Lock ", + "Section": "3. Logging and Monitoring", + "SubSection": "3.2 Retention", + "AttributeDescription": "Enabling retention policies on log storage buckets prevents logs from being overwritten or accidentally deleted. It is recommended to configure retention policies and enable Bucket Lock for all storage buckets used as log sinks.", + "AdditionalInformation": "Cloud Logging allows logs to be exported to storage buckets through sinks. Without a retention policy, logs can be altered or deleted, making it difficult to perform security investigations or comply with audit requirements. To ensure logs remain intact for forensics and security analysis: 1.Set a retention policy on log storage buckets to prevent early deletion. 2.Enable Bucket Lock to make the policy immutable, ensuring logs cannot be altered even by privileged users. 3.Apply appropriate access controls to protect logs from unauthorized access. By implementing retention policies and Bucket Lock, organizations preserve critical security logs, prevent attackers from covering their tracks, and enhance compliance with security regulations.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "3.3.1", + "Description": "Ensure Cloud Asset Inventory Is Enabled", + "Checks": [ + "iam_cloud_asset_inventory_enabled" + ], + "Attributes": [ + { + "Title": "Cloud Asset Inventory Enabled", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "Google Cloud Asset Inventory provides a historical view of GCP resources and IAM policies using a time-series database. It captures metadata on cloud resources, policy configurations, and runtime data. Enabling Cloud Asset Inventory allows for efficient searching and exporting of asset data.", + "AdditionalInformation": "Cloud Asset Inventory enhances security analysis, resource change tracking, and compliance auditing by maintaining a detailed history of GCP resources and their configurations. Enabling it across all GCP projects ensures visibility into changes, helping organizations detect misconfigurations, track policy changes, and strengthen security posture.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "3.3.2", + "Description": "Ensure 'Access Approval' is 'Enabled'", + "Checks": [ + "iam_account_access_approval_enabled" + ], + "Attributes": [ + { + "Title": "Access Aproval Enabled", + "Section": "3. Logging and Monitoring", + "SubSection": "3.3 Monitoring", + "AttributeDescription": "GCP Access Approval allows organizations to require explicit approval before Google support personnel can access their projects. Administrators can assign security roles in IAM to specific users who can review and approve these requests. Notifications of access requests, including the requesting Google employees details, are sent via email or Pub/Sub messages, providing transparency and control.", + "AdditionalInformation": "Managing who accesses your organizations data is critical for information security. While Google support may require access for troubleshooting, Access Approval ensures that access is only granted when explicitly authorized. This feature adds an additional layer of security and logging, ensuring that only approved Google personnel can access sensitive information.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "4.1.1", + "Description": "Ensure That DNSSEC Is Enabled for Cloud DNS ", + "Checks": [ + "dns_dnssec_disabled" + ], + "Attributes": [ + { + "Title": "DNSSEC Is Enabled for Cloud DNS ", + "Section": "4. Encryption", + "SubSection": "4.1 In-Transit", + "AttributeDescription": "Cloud DNS provides a scalable and reliable domain name system (DNS) service. Domain Name System Security Extensions (DNSSEC) enhance DNS security by protecting domains against DNS hijacking, man-in-the-middle attacks, and other threats.", + "AdditionalInformation": "DNSSEC cryptographically signs DNS records, ensuring the integrity and authenticity of DNS responses. Without DNSSEC, attackers can manipulate DNS lookups, redirecting users to malicious websites through DNS hijacking or spoofing attacks. Enabling DNSSEC helps prevent unauthorized modifications to DNS records, reducing the risk of phishing, malware distribution, and other cyber threats.", + "LevelOfRisk": 1 + } + ] + }, + { + "Id": "4.1.2", + "Description": "Ensure That the Cloud SQL Database Instance Requires All Incoming Connections To Use SSL", + "Checks": [ + "cloudsql_instance_ssl_connections" + ], + "Attributes": [ + { + "Title": "Cloud SQL Database Instance Requires All Incoming Connections To Use SSL", + "Section": "4. Encryption", + "SubSection": "4.1 In-Transit", + "AttributeDescription": "Require all incoming connections to SQL database instances to use SSL encryption.", + "AdditionalInformation": "Unencrypted SQL database connections are vulnerable to man-in-the-middle (MITM) attacks, which can expose sensitive data such as credentials, queries, and results. Enforcing SSL ensures secure communication by encrypting data in transit, protecting against interception and unauthorized access. This recommendation applies to PostgreSQL, MySQL (Generation 1 and 2), and SQL Server 2017 instances.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "4.1.3", + "Description": "Ensure That RSASHA1 Is Not Used for the Key-Signing Key in Cloud DNS DNSSEC", + "Checks": [ + "dns_rsasha1_in_use_to_key_sign_in_dnssec" + ], + "Attributes": [ + { + "Title": "RSASHA1 Is Not Used for the Key-Signing Key in Cloud DNS DNSSEC", + "Section": "4. Encryption", + "SubSection": "4.1 In-Transit", + "AttributeDescription": "DNSSEC (Domain Name System Security Extensions) relies on cryptographic algorithms to ensure the integrity and authenticity of DNS responses. It is important to use strong and recommended algorithms for key signing to maintain robust security. SHA-1 is deprecated and requires explicit approval from Google if used.", + "AdditionalInformation": "DNSSEC signing algorithms play a critical role in securing DNS transactions. Using weak or outdated algorithms can expose DNS infrastructure to spoofing, hijacking, and other attacks. Organizations should select recommended and secure algorithms when enabling DNSSEC to protect DNS records from unauthorized modifications. If adjustments to DNSSEC settings are required, DNSSEC must be disabled and re-enabled with the updated configurations.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "4.1.4", + "Description": "Ensure That RSASHA1 Is Not Used for the Zone-Signing Key in Cloud DNS DNSSEC", + "Checks": [ + "dns_rsasha1_in_use_to_zone_sign_in_dnssec" + ], + "Attributes": [ + { + "Title": "RSASHA1 Is Not Used for the Zone-Signing Key in Cloud DNS DNSSEC", + "Section": "4. Encryption", + "SubSection": "4.1 In-Transit", + "AttributeDescription": "DNSSEC (Domain Name System Security Extensions) enhances DNS security by using cryptographic algorithms for zone signing and transaction security. It is essential to use strong and recommended algorithms for key signing. SHA-1 has been deprecated and requires Googles explicit approval and a support contract if used.", + "AdditionalInformation": "Using weak or outdated cryptographic algorithms compromises DNS integrity and exposes systems to threats like spoofing and hijacking. Organizations should ensure that DNSSEC settings use strong, recommended algorithms. If DNSSEC is already enabled and changes are needed, it must be disabled and re-enabled with updated configurations to apply the changes effectively.", + "LevelOfRisk": 2 + } + ] + }, + { + "Id": "4.2.1", + "Description": "Ensure VM Disks for Critical VMs Are Encrypted With Customer-Supplied Encryption Keys (CSEK)", + "Checks": [ + "compute_instance_encryption_with_csek_enabled" + ], + "Attributes": [ + { + "Title": "VM Disks for Critical VMs Are Encrypted With Customer-Supplied Encryption Keys (CSEK)", + "Section": "4. Encryption", + "SubSection": "4.2 At-Rest", + "AttributeDescription": "Customer-Supplied Encryption Keys (CSEK) is a feature available in Google Cloud Storage and Google Compute Engine, allowing users to supply their own encryption keys. When you provide your key, Google uses it to protect the Google-generated keys that are responsible for encrypting and decrypting your data. By default, Google Compute Engine encrypts all data at rest automatically, managing this encryption for you with no additional action required. However, if you wish to have full control over the encryption process, you can choose to supply your own encryption keys.", + "AdditionalInformation": "By default, Compute Engine automatically encrypts all data at rest, with the service managing the encryption without any further input required from you or your application. However, if you require complete control over encryption, you have the option to provide your own encryption keys to manage the encryption of instance disks.", + "LevelOfRisk": 5 + } + ] + }, + { + "Id": "4.2.2", + "Description": "Ensure that Dataproc Cluster is encrypted using Customer-Managed Encryption Key", + "Checks": [ + "dataproc_encrypted_with_cmks_disabled" + ], + "Attributes": [ + { + "Title": "Dataproc Cluster is encrypted using Customer-Managed Encryption Key", + "Section": "4. Encryption", + "SubSection": "4.2 At-Rest", + "AttributeDescription": "When using Dataproc, the data associated with clusters and jobs is stored on Persistent Disks (PDs) linked to the Compute Engine VMs in your cluster and in a Cloud Storage staging bucket. This data is encrypted using a Google-generated Data Encryption Key (DEK) and a Key Encryption Key (KEK). The Customer-Managed Encryption Keys (CMEK) feature allows you to create, use, and revoke the KEK, although Google still controls the DEK used to encrypt the data.", + "AdditionalInformation": "Dataproc cluster data is encrypted using Google-managed keys: the Data Encryption Key (DEK) and the Key Encryption Key (KEK). If you wish to have control over the encryption of your cluster data, you can use your own Customer-Managed Keys (CMKs). Cloud KMS Customer-Managed Keys can add an extra layer of security and are commonly used in environments with strict compliance and security requirements.", + "LevelOfRisk": 4 + } + ] + }, + { + "Id": "4.2.3", + "Description": "Ensure BigQuery datasets are encrypted with Customer-Managed Keys (CMKs).", + "Checks": [ + "bigquery_dataset_cmk_encryption" + ], + "Attributes": [ + { + "Title": "BigQuery datasets are encrypted with Customer-Managed Keys (CMKs).", + "Section": "4. Encryption", + "SubSection": "4.2 At-Rest", + "AttributeDescription": "Ensure that BigQuery datasets are encrypted using Customer-Managed Keys (CMKs) to gain more granular control over the data encryption and decryption process.", + "AdditionalInformation": "For enhanced control over encryption, Customer-Managed Encryption Keys (CMEK) can be implemented as a key management solution for BigQuery datasets.", + "LevelOfRisk": 3 + } + ] + }, + { + "Id": "4.2.4", + "Description": "Ensure BigQuery tables are encrypted with Customer-Managed Keys (CMKs).", + "Checks": [ + "bigquery_table_cmk_encryption" + ], + "Attributes": [ + { + "Title": "BigQuery tables are encrypted with Customer-Managed Keys (CMKs).", + "Section": "4. Encryption", + "SubSection": "4.2 At-Rest", + "AttributeDescription": "Ensure that BigQuery tables are encrypted using Customer-Managed Keys (CMKs) for more granular control over the data encryption and decryption process.", + "AdditionalInformation": "For greater control over encryption, Customer-Managed Encryption Keys (CMEK) can be utilized as the key management solution for BigQuery tables.", + "LevelOfRisk": 3 + } + ] + } + ] +} diff --git a/prowler/lib/check/compliance_models.py b/prowler/lib/check/compliance_models.py index fff0d6c38e..92bfaec168 100644 --- a/prowler/lib/check/compliance_models.py +++ b/prowler/lib/check/compliance_models.py @@ -183,6 +183,18 @@ class KISA_ISMSP_Requirement_Attribute(BaseModel): NonComplianceCases: Optional[list[str]] +# Prowler ThreatScore Requirement Attribute +class Prowler_ThreatScore_Requirement_Attribute(BaseModel): + """Prowler ThreatScore Requirement Attribute""" + + Title: str + Section: str + SubSection: str + AttributeDescription: str + AdditionalInformation: str + LevelOfRisk: int + + # Base Compliance Model # TODO: move this to compliance folder class Compliance_Requirement(BaseModel): @@ -198,6 +210,7 @@ class Compliance_Requirement(BaseModel): ISO27001_2013_Requirement_Attribute, AWS_Well_Architected_Requirement_Attribute, KISA_ISMSP_Requirement_Attribute, + Prowler_ThreatScore_Requirement_Attribute, # Generic_Compliance_Requirement_Attribute must be the last one since it is the fallback for generic compliance framework Generic_Compliance_Requirement_Attribute, ] diff --git a/prowler/lib/outputs/compliance/compliance.py b/prowler/lib/outputs/compliance/compliance.py index b74eafa97f..e0c686dd84 100644 --- a/prowler/lib/outputs/compliance/compliance.py +++ b/prowler/lib/outputs/compliance/compliance.py @@ -11,6 +11,9 @@ from prowler.lib.outputs.compliance.kisa_ismsp.kisa_ismsp import get_kisa_ismsp_ from prowler.lib.outputs.compliance.mitre_attack.mitre_attack import ( get_mitre_attack_table, ) +from prowler.lib.outputs.compliance.prowler_threatscore.prowler_threatscore import ( + get_prowler_threatscore_table, +) def display_compliance_table( @@ -72,6 +75,15 @@ def display_compliance_table( output_directory, compliance_overview, ) + elif "threatscore_" in compliance_framework: + get_prowler_threatscore_table( + findings, + bulk_checks_metadata, + compliance_framework, + output_filename, + output_directory, + compliance_overview, + ) else: get_generic_compliance_table( findings, diff --git a/prowler/lib/outputs/compliance/prowler_threatscore/__init__.py b/prowler/lib/outputs/compliance/prowler_threatscore/__init__.py new file mode 100644 index 0000000000..e69de29bb2 diff --git a/prowler/lib/outputs/compliance/prowler_threatscore/models.py b/prowler/lib/outputs/compliance/prowler_threatscore/models.py new file mode 100644 index 0000000000..2b5f5ada66 --- /dev/null +++ b/prowler/lib/outputs/compliance/prowler_threatscore/models.py @@ -0,0 +1,81 @@ +from typing import Optional + +from pydantic import BaseModel + + +class ProwlerThreatScoreAWSModel(BaseModel): + """ + ProwlerThreatScoreAWSModel generates a finding's output in AWS Prowler ThreatScore Compliance format. + """ + + Provider: str + Description: str + AccountId: str + Region: str + AssessmentDate: str + Requirements_Id: str + Requirements_Description: str + Requirements_Attributes_Title: str + Requirements_Attributes_Section: str + Requirements_Attributes_SubSection: Optional[str] + Requirements_Attributes_AttributeDescription: str + Requirements_Attributes_AdditionalInformation: str + Requirements_Attributes_LevelOfRisk: int + Status: str + StatusExtended: str + ResourceId: str + ResourceName: str + CheckId: str + Muted: bool + + +class ProwlerThreatScoreAzureModel(BaseModel): + """ + ProwlerThreatScoreAzureModel generates a finding's output in Azure Prowler ThreatScore Compliance format. + """ + + Provider: str + Description: str + SubscriptionId: str + Location: str + AssessmentDate: str + Requirements_Id: str + Requirements_Description: str + Requirements_Attributes_Title: str + Requirements_Attributes_Section: str + Requirements_Attributes_SubSection: Optional[str] + Requirements_Attributes_AttributeDescription: str + Requirements_Attributes_AdditionalInformation: str + Requirements_Attributes_LevelOfRisk: int + Status: str + StatusExtended: str + ResourceId: str + ResourceName: str + CheckId: str + Muted: bool + + +class ProwlerThreatScoreGCPModel(BaseModel): + """ + ProwlerThreatScoreGCPModel generates a finding's output in GCP Prowler ThreatScore Compliance format. + """ + + Provider: str + Description: str + ProjectId: str + Location: str + AssessmentDate: str + Requirements_Id: str + Requirements_Description: str + Requirements_Attributes_Title: str + Requirements_Attributes_Section: str + Requirements_Attributes_SubSection: Optional[str] + Requirements_Attributes_AttributeDescription: str + Requirements_Attributes_AdditionalInformation: str + Requirements_Attributes_LevelOfRisk: int + Status: str + StatusExtended: str + ResourceId: str + ResourceName: str + CheckId: str + Muted: bool diff --git a/prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore.py b/prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore.py new file mode 100644 index 0000000000..e041e3e7f3 --- /dev/null +++ b/prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore.py @@ -0,0 +1,121 @@ +from colorama import Fore, Style +from tabulate import tabulate + +from prowler.config.config import orange_color + + +def get_prowler_threatscore_table( + findings: list, + bulk_checks_metadata: dict, + compliance_framework: str, + output_filename: str, + output_directory: str, + compliance_overview: bool, +): + pillar_table = { + "Provider": [], + "Pillar": [], + "Status": [], + "Score": [], + "Muted": [], + } + pass_count = [] + fail_count = [] + muted_count = [] + pillars = {} + score_per_pillar = {} + number_findings_per_pillar = {} + for index, finding in enumerate(findings): + check = bulk_checks_metadata[finding.check_metadata.CheckID] + check_compliances = check.Compliance + for compliance in check_compliances: + if compliance.Framework == "ProwlerThreatScore": + for requirement in compliance.Requirements: + for attribute in requirement.Attributes: + pillar = attribute.Section + + if pillar not in score_per_pillar.keys(): + score_per_pillar[pillar] = 0 + number_findings_per_pillar[pillar] = 0 + if finding.status == "FAIL" and not finding.muted: + score_per_pillar[pillar] += attribute.LevelOfRisk + number_findings_per_pillar[pillar] += 1 + + if pillar not in pillars: + pillars[pillar] = {"FAIL": 0, "PASS": 0, "Muted": 0} + + if finding.muted: + if index not in muted_count: + muted_count.append(index) + pillars[pillar]["Muted"] += 1 + else: + if finding.status == "FAIL" and index not in fail_count: + fail_count.append(index) + pillars[pillar]["FAIL"] += 1 + elif finding.status == "PASS" and index not in pass_count: + pass_count.append(index) + pillars[pillar]["PASS"] += 1 + + pillars = dict(sorted(pillars.items())) + for pillar in pillars: + pillar_table["Provider"].append(compliance.Provider) + pillar_table["Pillar"].append(pillar) + if number_findings_per_pillar[pillar] == 0: + pillar_table["Score"].append( + f"{Style.BRIGHT}{Fore.GREEN}0{Style.RESET_ALL}" + ) + else: + pillar_table["Score"].append( + f"{Style.BRIGHT}{Fore.RED}{score_per_pillar[pillar] / number_findings_per_pillar[pillar]:.2f}/5{Style.RESET_ALL}" + ) + if pillars[pillar]["FAIL"] > 0: + pillar_table["Status"].append( + f"{Fore.RED}FAIL({pillars[pillar]['FAIL']}){Style.RESET_ALL}" + ) + else: + pillar_table["Status"].append( + f"{Fore.GREEN}PASS({pillars[pillar]['PASS']}){Style.RESET_ALL}" + ) + pillar_table["Muted"].append( + f"{orange_color}{pillars[pillar]['Muted']}{Style.RESET_ALL}" + ) + + if ( + len(fail_count) + len(pass_count) + len(muted_count) > 1 + ): # If there are no resources, don't print the compliance table + print( + f"\nCompliance Status of {Fore.YELLOW}{compliance_framework.upper()}{Style.RESET_ALL} Framework:" + ) + total_findings_count = len(fail_count) + len(pass_count) + len(muted_count) + overview_table = [ + [ + f"{Fore.RED}{round(len(fail_count) / total_findings_count * 100, 2)}% ({len(fail_count)}) FAIL{Style.RESET_ALL}", + f"{Fore.GREEN}{round(len(pass_count) / total_findings_count * 100, 2)}% ({len(pass_count)}) PASS{Style.RESET_ALL}", + f"{orange_color}{round(len(muted_count) / total_findings_count * 100, 2)}% ({len(muted_count)}) MUTED{Style.RESET_ALL}", + ] + ] + print(tabulate(overview_table, tablefmt="rounded_grid")) + if not compliance_overview: + if len(fail_count) > 0 and len(pillar_table["Pillar"]) > 0: + print( + f"\nFramework {Fore.YELLOW}{compliance_framework.upper()}{Style.RESET_ALL} Results:" + ) + + print( + tabulate( + pillar_table, + tablefmt="rounded_grid", + headers="keys", + ) + ) + + print( + f"{Style.BRIGHT}\n=== Risk Score Guide ===\nScore ranges from 1 (lowest risk) to 5 (highest risk), indicating the severity of the potential impact.{Style.RESET_ALL}" + ) + print( + f"{Style.BRIGHT}(Only sections containing results appear, the score is calculated as the sum of the level of risk of the failed findings divided by the number of failed findings){Style.RESET_ALL}" + ) + print(f"\nDetailed results of {compliance_framework.upper()} are in:") + print( + f" - CSV: {output_directory}/compliance/{output_filename}_{compliance_framework}.csv\n" + ) diff --git a/prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_aws.py b/prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_aws.py new file mode 100644 index 0000000000..2d876b402f --- /dev/null +++ b/prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_aws.py @@ -0,0 +1,91 @@ +from prowler.lib.check.compliance_models import Compliance +from prowler.lib.outputs.compliance.compliance_output import ComplianceOutput +from prowler.lib.outputs.compliance.prowler_threatscore.models import ( + ProwlerThreatScoreAWSModel, +) +from prowler.lib.outputs.finding import Finding + + +class ProwlerThreatScoreAWS(ComplianceOutput): + """ + This class represents the AWS Prowler ThreatScore compliance output. + + Attributes: + - _data (list): A list to store transformed data from findings. + - _file_descriptor (TextIOWrapper): A file descriptor to write data to a file. + + Methods: + - transform: Transforms findings into AWS Prowler ThreatScore compliance format. + """ + + def transform( + self, + findings: list[Finding], + compliance: Compliance, + compliance_name: str, + ) -> None: + """ + Transforms a list of findings into AWS Prowler ThreatScore compliance format. + + Parameters: + - findings (list): A list of findings. + - compliance (Compliance): A compliance model. + - compliance_name (str): The name of the compliance model. + + Returns: + - None + """ + for finding in findings: + # Get the compliance requirements for the finding + finding_requirements = finding.compliance.get(compliance_name, []) + for requirement in compliance.Requirements: + if requirement.Id in finding_requirements: + for attribute in requirement.Attributes: + compliance_row = ProwlerThreatScoreAWSModel( + Provider=finding.provider, + Description=compliance.Description, + AccountId=finding.account_uid, + Region=finding.region, + AssessmentDate=str(finding.timestamp), + Requirements_Id=requirement.Id, + Requirements_Description=requirement.Description, + Requirements_Attributes_Title=attribute.Title, + Requirements_Attributes_Section=attribute.Section, + Requirements_Attributes_SubSection=attribute.SubSection, + Requirements_Attributes_AttributeDescription=attribute.AttributeDescription, + Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation, + Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk, + Status=finding.status, + StatusExtended=finding.status_extended, + ResourceId=finding.resource_uid, + ResourceName=finding.resource_name, + CheckId=finding.check_id, + Muted=finding.muted, + ) + self._data.append(compliance_row) + # Add manual requirements to the compliance output + for requirement in compliance.Requirements: + if not requirement.Checks: + for attribute in requirement.Attributes: + compliance_row = ProwlerThreatScoreAWSModel( + Provider=compliance.Provider.lower(), + Description=compliance.Description, + AccountId="", + Region="", + AssessmentDate=str(finding.timestamp), + Requirements_Id=requirement.Id, + Requirements_Description=requirement.Description, + Requirements_Attributes_Title=attribute.Title, + Requirements_Attributes_Section=attribute.Section, + Requirements_Attributes_SubSection=attribute.SubSection, + Requirements_Attributes_AttributeDescription=attribute.AttributeDescription, + Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation, + Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk, + Status="MANUAL", + StatusExtended="Manual check", + ResourceId="manual_check", + ResourceName="Manual check", + CheckId="manual", + Muted=False, + ) + self._data.append(compliance_row) diff --git a/prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_azure.py b/prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_azure.py new file mode 100644 index 0000000000..01786e2d08 --- /dev/null +++ b/prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_azure.py @@ -0,0 +1,91 @@ +from prowler.lib.check.compliance_models import Compliance +from prowler.lib.outputs.compliance.compliance_output import ComplianceOutput +from prowler.lib.outputs.compliance.prowler_threatscore.models import ( + ProwlerThreatScoreAzureModel, +) +from prowler.lib.outputs.finding import Finding + + +class ProwlerThreatScoreAzure(ComplianceOutput): + """ + This class represents the Azure Prowler ThreatScore compliance output. + + Attributes: + - _data (list): A list to store transformed data from findings. + - _file_descriptor (TextIOWrapper): A file descriptor to write data to a file. + + Methods: + - transform: Transforms findings into Azure Prowler ThreatScore compliance format. + """ + + def transform( + self, + findings: list[Finding], + compliance: Compliance, + compliance_name: str, + ) -> None: + """ + Transforms a list of findings into Azure Prowler ThreatScore compliance format. + + Parameters: + - findings (list): A list of findings. + - compliance (Compliance): A compliance model. + - compliance_name (str): The name of the compliance model. + + Returns: + - None + """ + for finding in findings: + # Get the compliance requirements for the finding + finding_requirements = finding.compliance.get(compliance_name, []) + for requirement in compliance.Requirements: + if requirement.Id in finding_requirements: + for attribute in requirement.Attributes: + compliance_row = ProwlerThreatScoreAzureModel( + Provider=finding.provider, + Description=compliance.Description, + SubscriptionId=finding.account_uid, + Location=finding.region, + AssessmentDate=str(finding.timestamp), + Requirements_Id=requirement.Id, + Requirements_Description=requirement.Description, + Requirements_Attributes_Title=attribute.Title, + Requirements_Attributes_Section=attribute.Section, + Requirements_Attributes_SubSection=attribute.SubSection, + Requirements_Attributes_AttributeDescription=attribute.AttributeDescription, + Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation, + Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk, + Status=finding.status, + StatusExtended=finding.status_extended, + ResourceId=finding.resource_uid, + ResourceName=finding.resource_name, + CheckId=finding.check_id, + Muted=finding.muted, + ) + self._data.append(compliance_row) + # Add manual requirements to the compliance output + for requirement in compliance.Requirements: + if not requirement.Checks: + for attribute in requirement.Attributes: + compliance_row = ProwlerThreatScoreAzureModel( + Provider=compliance.Provider.lower(), + Description=compliance.Description, + SubscriptionId="", + Location="", + AssessmentDate=str(finding.timestamp), + Requirements_Id=requirement.Id, + Requirements_Description=requirement.Description, + Requirements_Attributes_Title=attribute.Title, + Requirements_Attributes_Section=attribute.Section, + Requirements_Attributes_SubSection=attribute.SubSection, + Requirements_Attributes_AttributeDescription=attribute.AttributeDescription, + Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation, + Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk, + Status="MANUAL", + StatusExtended="Manual check", + ResourceId="manual_check", + ResourceName="Manual check", + CheckId="manual", + Muted=False, + ) + self._data.append(compliance_row) diff --git a/prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_gcp.py b/prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_gcp.py new file mode 100644 index 0000000000..9bf577255f --- /dev/null +++ b/prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_gcp.py @@ -0,0 +1,91 @@ +from prowler.lib.check.compliance_models import Compliance +from prowler.lib.outputs.compliance.compliance_output import ComplianceOutput +from prowler.lib.outputs.compliance.prowler_threatscore.models import ( + ProwlerThreatScoreGCPModel, +) +from prowler.lib.outputs.finding import Finding + + +class ProwlerThreatScoreGCP(ComplianceOutput): + """ + This class represents the GCP Prowler ThreatScore compliance output. + + Attributes: + - _data (list): A list to store transformed data from findings. + - _file_descriptor (TextIOWrapper): A file descriptor to write data to a file. + + Methods: + - transform: Transforms findings into GCP Prowler ThreatScore compliance format. + """ + + def transform( + self, + findings: list[Finding], + compliance: Compliance, + compliance_name: str, + ) -> None: + """ + Transforms a list of findings into GCP Prowler ThreatScore compliance format. + + Parameters: + - findings (list): A list of findings. + - compliance (Compliance): A compliance model. + - compliance_name (str): The name of the compliance model. + + Returns: + - None + """ + for finding in findings: + # Get the compliance requirements for the finding + finding_requirements = finding.compliance.get(compliance_name, []) + for requirement in compliance.Requirements: + if requirement.Id in finding_requirements: + for attribute in requirement.Attributes: + compliance_row = ProwlerThreatScoreGCPModel( + Provider=finding.provider, + Description=compliance.Description, + ProjectId=finding.account_uid, + Location=finding.region, + AssessmentDate=str(finding.timestamp), + Requirements_Id=requirement.Id, + Requirements_Description=requirement.Description, + Requirements_Attributes_Title=attribute.Title, + Requirements_Attributes_Section=attribute.Section, + Requirements_Attributes_SubSection=attribute.SubSection, + Requirements_Attributes_AttributeDescription=attribute.AttributeDescription, + Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation, + Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk, + Status=finding.status, + StatusExtended=finding.status_extended, + ResourceId=finding.resource_uid, + ResourceName=finding.resource_name, + CheckId=finding.check_id, + Muted=finding.muted, + ) + self._data.append(compliance_row) + # Add manual requirements to the compliance output + for requirement in compliance.Requirements: + if not requirement.Checks: + for attribute in requirement.Attributes: + compliance_row = ProwlerThreatScoreGCPModel( + Provider=compliance.Provider.lower(), + Description=compliance.Description, + ProjectId="", + Location="", + AssessmentDate=str(finding.timestamp), + Requirements_Id=requirement.Id, + Requirements_Description=requirement.Description, + Requirements_Attributes_Title=attribute.Title, + Requirements_Attributes_Section=attribute.Section, + Requirements_Attributes_SubSection=attribute.SubSection, + Requirements_Attributes_AttributeDescription=attribute.AttributeDescription, + Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation, + Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk, + Status="MANUAL", + StatusExtended="Manual check", + ResourceId="manual_check", + ResourceName="Manual check", + CheckId="manual", + Muted=False, + ) + self._data.append(compliance_row) diff --git a/prowler_threatscore_aws b/prowler_threatscore_aws new file mode 100644 index 0000000000..e69de29bb2 diff --git a/prowler_threatscore_azure b/prowler_threatscore_azure new file mode 100644 index 0000000000..e69de29bb2 diff --git a/prowler_threatscore_gcp b/prowler_threatscore_gcp new file mode 100644 index 0000000000..e69de29bb2 diff --git a/tests/lib/outputs/compliance/fixtures.py b/tests/lib/outputs/compliance/fixtures.py index f20cf6de85..3c8b71e3cd 100644 --- a/tests/lib/outputs/compliance/fixtures.py +++ b/tests/lib/outputs/compliance/fixtures.py @@ -13,6 +13,7 @@ from prowler.lib.check.compliance_models import ( Mitre_Requirement_Attribute_AWS, Mitre_Requirement_Attribute_Azure, Mitre_Requirement_Attribute_GCP, + Prowler_ThreatScore_Requirement_Attribute, ) CIS_1_4_AWS_NAME = "cis_1.4_aws" @@ -803,3 +804,129 @@ KISA_ISMSP_AWS = Compliance( ), ], ) + +PROWLER_THREATSCORE_AWS_NAME = "prowler_threatscore_aws" +PROWLER_THREATSCORE_AWS = Compliance( + Framework="ProwlerThreatScore", + Version="1.0", + Provider="AWS", + Description="Prowler ThreatScore Compliance Framework for AWS ensures that the AWS account is compliant taking into account four main pillars: Identity and Access Management, Attack Surface, Forensic Readiness and Encryption", + Requirements=[ + Compliance_Requirement( + Id="1.1.1", + Description="Ensure MFA is enabled for the 'root' user account", + Attributes=[ + Prowler_ThreatScore_Requirement_Attribute( + Title="MFA enabled for 'root'", + Section="1. IAM", + SubSection="1.1 Authentication", + AttributeDescription="The root user account holds the highest level of privileges within an AWS account. Enabling Multi-Factor Authentication (MFA) enhances security by adding an additional layer of protection beyond just a username and password. With MFA activated, users must provide their credentials (username and password) along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.", + AdditionalInformation="Enabling MFA enhances console security by requiring the authenticating user to both possess a time-sensitive key-generating device and have knowledge of their credentials.", + LevelOfRisk=5, + ) + ], + Checks=[ + "iam_root_mfa_enabled", + ], + ), + Compliance_Requirement( + Id="1.1.2", + Description="Ensure hardware MFA is enabled for the 'root' user account", + Attributes=[ + Prowler_ThreatScore_Requirement_Attribute( + Title="CloudTrail logging enabled", + Section="1. IAM", + SubSection="1.1 Authentication", + AttributeDescription="The root user account in AWS has the highest level of privileges. Multi-Factor Authentication (MFA) enhances security by adding an extra layer of protection beyond a username and password. When MFA is enabled, users must enter their credentials along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.", + AdditionalInformation="A hardware MFA has a smaller attack surface compared to a virtual MFA. Unlike a virtual MFA, which relies on a mobile device that may be vulnerable to malware or compromise, a hardware MFA operates independently, reducing exposure to potential security threats.", + LevelOfRisk=3, + ) + ], + Checks=[], + ), + ], +) + +PROWLER_THREATSCORE_AZURE_NAME = "prowler_threatscore_azure" +PROWLER_THREATSCORE_AZURE = Compliance( + Framework="ProwlerThreatScore", + Version="1.0", + Provider="Azure", + Description="Prowler ThreatScore Compliance Framework for Azure ensures that the Azure account is compliant taking into account four main pillars: Identity and Access Management, Attack Surface, Forensic Readiness and Encryption", + Requirements=[ + Compliance_Requirement( + Id="1.1.1", + Description="Ensure MFA is enabled for the 'root' user account", + Attributes=[ + Prowler_ThreatScore_Requirement_Attribute( + Title="MFA enabled for 'root'", + Section="1. IAM", + SubSection="1.1 Authentication", + AttributeDescription="The root user account holds the highest level of privileges within an AWS account. Enabling Multi-Factor Authentication (MFA) enhances security by adding an additional layer of protection beyond just a username and password. With MFA activated, users must provide their credentials (username and password) along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.", + AdditionalInformation="Enabling MFA enhances console security by requiring the authenticating user to both possess a time-sensitive key-generating device and have knowledge of their credentials.", + LevelOfRisk=5, + ) + ], + Checks=[ + "iam_root_mfa_enabled", + ], + ), + Compliance_Requirement( + Id="1.1.2", + Description="Ensure hardware MFA is enabled for the 'root' user account", + Attributes=[ + Prowler_ThreatScore_Requirement_Attribute( + Title="CloudTrail logging enabled", + Section="1. IAM", + SubSection="1.1 Authentication", + AttributeDescription="The root user account in AWS has the highest level of privileges. Multi-Factor Authentication (MFA) enhances security by adding an extra layer of protection beyond a username and password. When MFA is enabled, users must enter their credentials along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.", + AdditionalInformation="A hardware MFA has a smaller attack surface compared to a virtual MFA. Unlike a virtual MFA, which relies on a mobile device that may be vulnerable to malware or compromise, a hardware MFA operates independently, reducing exposure to potential security threats.", + LevelOfRisk=3, + ) + ], + Checks=[], + ), + ], +) + +PROWLER_THREATSCORE_GCP_NAME = "prowler_threatscore_gcp" +PROWLER_THREATSCORE_GCP = Compliance( + Framework="ProwlerThreatScore", + Version="1.0", + Provider="GCP", + Description="Prowler ThreatScore Compliance Framework for GCP ensures that the GCP account is compliant taking into account four main pillars: Identity and Access Management, Attack Surface, Forensic Readiness and Encryption", + Requirements=[ + Compliance_Requirement( + Id="1.1.1", + Description="Ensure MFA is enabled for the 'root' user account", + Attributes=[ + Prowler_ThreatScore_Requirement_Attribute( + Title="MFA enabled for 'root'", + Section="1. IAM", + SubSection="1.1 Authentication", + AttributeDescription="The root user account holds the highest level of privileges within an AWS account. Enabling Multi-Factor Authentication (MFA) enhances security by adding an additional layer of protection beyond just a username and password. With MFA activated, users must provide their credentials (username and password) along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.", + AdditionalInformation="Enabling MFA enhances console security by requiring the authenticating user to both possess a time-sensitive key-generating device and have knowledge of their credentials.", + LevelOfRisk=5, + ) + ], + Checks=[ + "iam_root_mfa_enabled", + ], + ), + Compliance_Requirement( + Id="1.1.2", + Description="Ensure hardware MFA is enabled for the 'root' user account", + Attributes=[ + Prowler_ThreatScore_Requirement_Attribute( + Title="CloudTrail logging enabled", + Section="1. IAM", + SubSection="1.1 Authentication", + AttributeDescription="The root user account in AWS has the highest level of privileges. Multi-Factor Authentication (MFA) enhances security by adding an extra layer of protection beyond a username and password. When MFA is enabled, users must enter their credentials along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.", + AdditionalInformation="A hardware MFA has a smaller attack surface compared to a virtual MFA. Unlike a virtual MFA, which relies on a mobile device that may be vulnerable to malware or compromise, a hardware MFA operates independently, reducing exposure to potential security threats.", + LevelOfRisk=3, + ) + ], + Checks=[], + ), + ], +) diff --git a/tests/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_aws_test.py b/tests/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_aws_test.py new file mode 100644 index 0000000000..28cf82ab44 --- /dev/null +++ b/tests/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_aws_test.py @@ -0,0 +1,140 @@ +from datetime import datetime +from io import StringIO + +from freezegun import freeze_time +from mock import patch + +from prowler.lib.outputs.compliance.prowler_threatscore.models import ( + ProwlerThreatScoreAWSModel, +) +from prowler.lib.outputs.compliance.prowler_threatscore.prowler_threatscore_aws import ( + ProwlerThreatScoreAWS, +) +from tests.lib.outputs.compliance.fixtures import ( + PROWLER_THREATSCORE_AWS, + PROWLER_THREATSCORE_AWS_NAME, +) +from tests.lib.outputs.fixtures.fixtures import generate_finding_output +from tests.providers.aws.utils import AWS_ACCOUNT_NUMBER, AWS_REGION_EU_WEST_1 + + +class TestProwlerThreatScoreAWS: + def test_output_transform(self): + findings = [ + generate_finding_output(compliance={"ProwlerThreatScore-1.0": "1.1.1"}) + ] + + output = ProwlerThreatScoreAWS( + findings, PROWLER_THREATSCORE_AWS, PROWLER_THREATSCORE_AWS_NAME + ) + output_data = output.data[0] + assert isinstance(output_data, ProwlerThreatScoreAWSModel) + assert output_data.Provider == "aws" + assert output_data.Description == PROWLER_THREATSCORE_AWS.Description + assert output_data.AccountId == AWS_ACCOUNT_NUMBER + assert output_data.Region == AWS_REGION_EU_WEST_1 + assert output_data.Requirements_Id == PROWLER_THREATSCORE_AWS.Requirements[0].Id + assert ( + output_data.Requirements_Description + == PROWLER_THREATSCORE_AWS.Requirements[0].Description + ) + assert ( + output_data.Requirements_Attributes_Title + == PROWLER_THREATSCORE_AWS.Requirements[0].Attributes[0].Title + ) + assert ( + output_data.Requirements_Attributes_Section + == PROWLER_THREATSCORE_AWS.Requirements[0].Attributes[0].Section + ) + assert ( + output_data.Requirements_Attributes_SubSection + == PROWLER_THREATSCORE_AWS.Requirements[0].Attributes[0].SubSection + ) + assert ( + output_data.Requirements_Attributes_AttributeDescription + == PROWLER_THREATSCORE_AWS.Requirements[0] + .Attributes[0] + .AttributeDescription + ) + assert ( + output_data.Requirements_Attributes_AdditionalInformation + == PROWLER_THREATSCORE_AWS.Requirements[0] + .Attributes[0] + .AdditionalInformation + ) + assert ( + output_data.Requirements_Attributes_LevelOfRisk + == PROWLER_THREATSCORE_AWS.Requirements[0].Attributes[0].LevelOfRisk + ) + assert output_data.Status == "PASS" + assert output_data.StatusExtended == "" + assert output_data.ResourceId == "" + assert output_data.ResourceName == "" + assert output_data.CheckId == "test-check-id" + assert not output_data.Muted + # Test manual check + output_data_manual = output.data[1] + assert output_data_manual.Provider == "aws" + assert output_data_manual.AccountId == "" + assert output_data_manual.Region == "" + assert ( + output_data_manual.Requirements_Id + == PROWLER_THREATSCORE_AWS.Requirements[1].Id + ) + assert ( + output_data_manual.Requirements_Description + == PROWLER_THREATSCORE_AWS.Requirements[1].Description + ) + assert ( + output_data_manual.Requirements_Attributes_Title + == PROWLER_THREATSCORE_AWS.Requirements[1].Attributes[0].Title + ) + assert ( + output_data_manual.Requirements_Attributes_Section + == PROWLER_THREATSCORE_AWS.Requirements[1].Attributes[0].Section + ) + assert ( + output_data_manual.Requirements_Attributes_SubSection + == PROWLER_THREATSCORE_AWS.Requirements[1].Attributes[0].SubSection + ) + assert ( + output_data_manual.Requirements_Attributes_AttributeDescription + == PROWLER_THREATSCORE_AWS.Requirements[1] + .Attributes[0] + .AttributeDescription + ) + assert ( + output_data_manual.Requirements_Attributes_AdditionalInformation + == PROWLER_THREATSCORE_AWS.Requirements[1] + .Attributes[0] + .AdditionalInformation + ) + assert ( + output_data_manual.Requirements_Attributes_LevelOfRisk + == PROWLER_THREATSCORE_AWS.Requirements[1].Attributes[0].LevelOfRisk + ) + assert output_data_manual.Status == "MANUAL" + assert output_data_manual.StatusExtended == "Manual check" + assert output_data_manual.ResourceId == "manual_check" + assert output_data_manual.ResourceName == "Manual check" + assert output_data_manual.CheckId == "manual" + assert not output_data_manual.Muted + + @freeze_time(datetime.now()) + def test_batch_write_data_to_file(self): + mock_file = StringIO() + findings = [ + generate_finding_output(compliance={"ProwlerThreatScore-1.0": "1.1.1"}) + ] + output = ProwlerThreatScoreAWS( + findings, PROWLER_THREATSCORE_AWS, PROWLER_THREATSCORE_AWS_NAME + ) + output._file_descriptor = mock_file + + with patch.object(mock_file, "close", return_value=None): + output.batch_write_data_to_file() + + mock_file.seek(0) + content = mock_file.read() + expected_csv = f"PROVIDER;DESCRIPTION;ACCOUNTID;REGION;ASSESSMENTDATE;REQUIREMENTS_ID;REQUIREMENTS_DESCRIPTION;REQUIREMENTS_ATTRIBUTES_TITLE;REQUIREMENTS_ATTRIBUTES_SECTION;REQUIREMENTS_ATTRIBUTES_SUBSECTION;REQUIREMENTS_ATTRIBUTES_ATTRIBUTEDESCRIPTION;REQUIREMENTS_ATTRIBUTES_ADDITIONALINFORMATION;REQUIREMENTS_ATTRIBUTES_LEVELOFRISK;STATUS;STATUSEXTENDED;RESOURCEID;RESOURCENAME;CHECKID;MUTED\r\naws;Prowler ThreatScore Compliance Framework for AWS ensures that the AWS account is compliant taking into account four main pillars: Identity and Access Management, Attack Surface, Forensic Readiness and Encryption;123456789012;eu-west-1;{datetime.now()};1.1.1;Ensure MFA is enabled for the 'root' user account;MFA enabled for 'root';1. IAM;1.1 Authentication;The root user account holds the highest level of privileges within an AWS account. Enabling Multi-Factor Authentication (MFA) enhances security by adding an additional layer of protection beyond just a username and password. With MFA activated, users must provide their credentials (username and password) along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.;Enabling MFA enhances console security by requiring the authenticating user to both possess a time-sensitive key-generating device and have knowledge of their credentials.;5;PASS;;;;test-check-id;False\r\naws;Prowler ThreatScore Compliance Framework for AWS ensures that the AWS account is compliant taking into account four main pillars: Identity and Access Management, Attack Surface, Forensic Readiness and Encryption;;;{datetime.now()};1.1.2;Ensure hardware MFA is enabled for the 'root' user account;CloudTrail logging enabled;1. IAM;1.1 Authentication;The root user account in AWS has the highest level of privileges. Multi-Factor Authentication (MFA) enhances security by adding an extra layer of protection beyond a username and password. When MFA is enabled, users must enter their credentials along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.;A hardware MFA has a smaller attack surface compared to a virtual MFA. Unlike a virtual MFA, which relies on a mobile device that may be vulnerable to malware or compromise, a hardware MFA operates independently, reducing exposure to potential security threats.;3;MANUAL;Manual check;manual_check;Manual check;manual;False\r\n" + assert content == expected_csv diff --git a/tests/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_azure_test.py b/tests/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_azure_test.py new file mode 100644 index 0000000000..0dec129f06 --- /dev/null +++ b/tests/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_azure_test.py @@ -0,0 +1,150 @@ +from datetime import datetime +from io import StringIO + +from freezegun import freeze_time +from mock import patch + +from prowler.lib.outputs.compliance.prowler_threatscore.models import ( + ProwlerThreatScoreAzureModel, +) +from prowler.lib.outputs.compliance.prowler_threatscore.prowler_threatscore_azure import ( + ProwlerThreatScoreAzure, +) +from tests.lib.outputs.compliance.fixtures import ( + PROWLER_THREATSCORE_AZURE, + PROWLER_THREATSCORE_AZURE_NAME, +) +from tests.lib.outputs.fixtures.fixtures import generate_finding_output +from tests.providers.azure.azure_fixtures import ( + AZURE_SUBSCRIPTION_ID, + AZURE_SUBSCRIPTION_NAME, +) + + +class TestProwlerThreatScoreAzure: + def test_output_transform(self): + findings = [ + generate_finding_output( + compliance={"ProwlerThreatScore-1.0": "1.1.1"}, + provider="azure", + account_name=AZURE_SUBSCRIPTION_NAME, + account_uid=AZURE_SUBSCRIPTION_ID, + region="", + ) + ] + + output = ProwlerThreatScoreAzure( + findings, PROWLER_THREATSCORE_AZURE, PROWLER_THREATSCORE_AZURE_NAME + ) + output_data = output.data[0] + assert isinstance(output_data, ProwlerThreatScoreAzureModel) + assert output_data.Provider == "azure" + assert output_data.Description == PROWLER_THREATSCORE_AZURE.Description + assert output_data.SubscriptionId == AZURE_SUBSCRIPTION_ID + assert output_data.Location == "" + assert ( + output_data.Requirements_Id == PROWLER_THREATSCORE_AZURE.Requirements[0].Id + ) + assert ( + output_data.Requirements_Description + == PROWLER_THREATSCORE_AZURE.Requirements[0].Description + ) + assert ( + output_data.Requirements_Attributes_Title + == PROWLER_THREATSCORE_AZURE.Requirements[0].Attributes[0].Title + ) + assert ( + output_data.Requirements_Attributes_Section + == PROWLER_THREATSCORE_AZURE.Requirements[0].Attributes[0].Section + ) + assert ( + output_data.Requirements_Attributes_SubSection + == PROWLER_THREATSCORE_AZURE.Requirements[0].Attributes[0].SubSection + ) + assert ( + output_data.Requirements_Attributes_AttributeDescription + == PROWLER_THREATSCORE_AZURE.Requirements[0] + .Attributes[0] + .AttributeDescription + ) + assert ( + output_data.Requirements_Attributes_AdditionalInformation + == PROWLER_THREATSCORE_AZURE.Requirements[0] + .Attributes[0] + .AdditionalInformation + ) + assert ( + output_data.Requirements_Attributes_LevelOfRisk + == PROWLER_THREATSCORE_AZURE.Requirements[0].Attributes[0].LevelOfRisk + ) + assert output_data.Status == "PASS" + assert output_data.StatusExtended == "" + assert output_data.ResourceId == "" + assert output_data.ResourceName == "" + assert output_data.CheckId == "test-check-id" + assert not output_data.Muted + # Test manual check + output_data_manual = output.data[1] + assert output_data_manual.Provider == "azure" + assert output_data_manual.SubscriptionId == "" + assert output_data_manual.Location == "" + assert ( + output_data_manual.Requirements_Id + == PROWLER_THREATSCORE_AZURE.Requirements[1].Id + ) + assert ( + output_data_manual.Requirements_Description + == PROWLER_THREATSCORE_AZURE.Requirements[1].Description + ) + assert ( + output_data_manual.Requirements_Attributes_Title + == PROWLER_THREATSCORE_AZURE.Requirements[1].Attributes[0].Title + ) + assert ( + output_data_manual.Requirements_Attributes_Section + == PROWLER_THREATSCORE_AZURE.Requirements[1].Attributes[0].Section + ) + assert ( + output_data_manual.Requirements_Attributes_SubSection + == PROWLER_THREATSCORE_AZURE.Requirements[1].Attributes[0].SubSection + ) + assert ( + output_data_manual.Requirements_Attributes_AttributeDescription + == PROWLER_THREATSCORE_AZURE.Requirements[1] + .Attributes[0] + .AttributeDescription + ) + assert ( + output_data_manual.Requirements_Attributes_AdditionalInformation + == PROWLER_THREATSCORE_AZURE.Requirements[1] + .Attributes[0] + .AdditionalInformation + ) + assert ( + output_data_manual.Requirements_Attributes_LevelOfRisk + == PROWLER_THREATSCORE_AZURE.Requirements[1].Attributes[0].LevelOfRisk + ) + assert output_data_manual.Status == "MANUAL" + assert output_data_manual.StatusExtended == "Manual check" + assert output_data_manual.ResourceId == "manual_check" + assert output_data_manual.ResourceName == "Manual check" + assert output_data_manual.CheckId == "manual" + + @freeze_time(datetime.now()) + def test_batch_write_data_to_file(self): + mock_file = StringIO() + findings = [ + generate_finding_output(compliance={"ProwlerThreatScore-1.0": "1.1.1"}) + ] + output = ProwlerThreatScoreAzure( + findings, PROWLER_THREATSCORE_AZURE, PROWLER_THREATSCORE_AZURE_NAME + ) + output._file_descriptor = mock_file + + with patch.object(mock_file, "close", return_value=None): + output.batch_write_data_to_file() + + mock_file.seek(0) + content = mock_file.read() + expected_csv = f"PROVIDER;DESCRIPTION;SUBSCRIPTIONID;LOCATION;ASSESSMENTDATE;REQUIREMENTS_ID;REQUIREMENTS_DESCRIPTION;REQUIREMENTS_ATTRIBUTES_TITLE;REQUIREMENTS_ATTRIBUTES_SECTION;REQUIREMENTS_ATTRIBUTES_SUBSECTION;REQUIREMENTS_ATTRIBUTES_ATTRIBUTEDESCRIPTION;REQUIREMENTS_ATTRIBUTES_ADDITIONALINFORMATION;REQUIREMENTS_ATTRIBUTES_LEVELOFRISK;STATUS;STATUSEXTENDED;RESOURCEID;RESOURCENAME;CHECKID;MUTED\r\naws;Prowler ThreatScore Compliance Framework for Azure ensures that the Azure account is compliant taking into account four main pillars: Identity and Access Management, Attack Surface, Forensic Readiness and Encryption;123456789012;eu-west-1;{datetime.now()};1.1.1;Ensure MFA is enabled for the 'root' user account;MFA enabled for 'root';1. IAM;1.1 Authentication;The root user account holds the highest level of privileges within an AWS account. Enabling Multi-Factor Authentication (MFA) enhances security by adding an additional layer of protection beyond just a username and password. With MFA activated, users must provide their credentials (username and password) along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.;Enabling MFA enhances console security by requiring the authenticating user to both possess a time-sensitive key-generating device and have knowledge of their credentials.;5;PASS;;;;test-check-id;False\r\nazure;Prowler ThreatScore Compliance Framework for Azure ensures that the Azure account is compliant taking into account four main pillars: Identity and Access Management, Attack Surface, Forensic Readiness and Encryption;;;{datetime.now()};1.1.2;Ensure hardware MFA is enabled for the 'root' user account;CloudTrail logging enabled;1. IAM;1.1 Authentication;The root user account in AWS has the highest level of privileges. Multi-Factor Authentication (MFA) enhances security by adding an extra layer of protection beyond a username and password. When MFA is enabled, users must enter their credentials along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.;A hardware MFA has a smaller attack surface compared to a virtual MFA. Unlike a virtual MFA, which relies on a mobile device that may be vulnerable to malware or compromise, a hardware MFA operates independently, reducing exposure to potential security threats.;3;MANUAL;Manual check;manual_check;Manual check;manual;False\r\n" + assert content == expected_csv diff --git a/tests/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_gcp_test.py b/tests/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_gcp_test.py new file mode 100644 index 0000000000..40a5e60494 --- /dev/null +++ b/tests/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_gcp_test.py @@ -0,0 +1,147 @@ +from datetime import datetime +from io import StringIO + +from freezegun import freeze_time +from mock import patch + +from prowler.lib.outputs.compliance.prowler_threatscore.models import ( + ProwlerThreatScoreGCPModel, +) +from prowler.lib.outputs.compliance.prowler_threatscore.prowler_threatscore_gcp import ( + ProwlerThreatScoreGCP, +) +from tests.lib.outputs.compliance.fixtures import ( + PROWLER_THREATSCORE_GCP, + PROWLER_THREATSCORE_GCP_NAME, +) +from tests.lib.outputs.fixtures.fixtures import generate_finding_output +from tests.providers.gcp.gcp_fixtures import GCP_PROJECT_ID + + +class TestProwlerThreatScoreGCP: + def test_output_transform(self): + findings = [ + generate_finding_output( + compliance={"ProwlerThreatScore-1.0": "1.1.1"}, + provider="gcp", + account_name=GCP_PROJECT_ID, + account_uid=GCP_PROJECT_ID, + region="", + ) + ] + + output = ProwlerThreatScoreGCP( + findings, PROWLER_THREATSCORE_GCP, PROWLER_THREATSCORE_GCP_NAME + ) + output_data = output.data[0] + assert isinstance(output_data, ProwlerThreatScoreGCPModel) + assert output_data.Provider == "gcp" + assert output_data.Description == PROWLER_THREATSCORE_GCP.Description + assert output_data.ProjectId == GCP_PROJECT_ID + assert output_data.Location == "" + assert output_data.Requirements_Id == PROWLER_THREATSCORE_GCP.Requirements[0].Id + assert ( + output_data.Requirements_Description + == PROWLER_THREATSCORE_GCP.Requirements[0].Description + ) + assert ( + output_data.Requirements_Attributes_Title + == PROWLER_THREATSCORE_GCP.Requirements[0].Attributes[0].Title + ) + assert ( + output_data.Requirements_Attributes_Section + == PROWLER_THREATSCORE_GCP.Requirements[0].Attributes[0].Section + ) + assert ( + output_data.Requirements_Attributes_SubSection + == PROWLER_THREATSCORE_GCP.Requirements[0].Attributes[0].SubSection + ) + assert ( + output_data.Requirements_Attributes_AttributeDescription + == PROWLER_THREATSCORE_GCP.Requirements[0] + .Attributes[0] + .AttributeDescription + ) + assert ( + output_data.Requirements_Attributes_AdditionalInformation + == PROWLER_THREATSCORE_GCP.Requirements[0] + .Attributes[0] + .AdditionalInformation + ) + assert ( + output_data.Requirements_Attributes_LevelOfRisk + == PROWLER_THREATSCORE_GCP.Requirements[0].Attributes[0].LevelOfRisk + ) + assert output_data.Status == "PASS" + assert output_data.StatusExtended == "" + assert output_data.ResourceId == "" + assert output_data.ResourceName == "" + assert output_data.CheckId == "test-check-id" + assert not output_data.Muted + # Test manual check + output_data_manual = output.data[1] + assert output_data_manual.Provider == "gcp" + assert output_data_manual.ProjectId == "" + assert output_data_manual.Location == "" + assert ( + output_data_manual.Requirements_Id + == PROWLER_THREATSCORE_GCP.Requirements[1].Id + ) + assert ( + output_data_manual.Requirements_Description + == PROWLER_THREATSCORE_GCP.Requirements[1].Description + ) + assert ( + output_data_manual.Requirements_Attributes_Title + == PROWLER_THREATSCORE_GCP.Requirements[1].Attributes[0].Title + ) + assert ( + output_data_manual.Requirements_Attributes_Section + == PROWLER_THREATSCORE_GCP.Requirements[1].Attributes[0].Section + ) + assert ( + output_data_manual.Requirements_Attributes_SubSection + == PROWLER_THREATSCORE_GCP.Requirements[1].Attributes[0].SubSection + ) + assert ( + output_data_manual.Requirements_Attributes_AttributeDescription + == PROWLER_THREATSCORE_GCP.Requirements[1] + .Attributes[0] + .AttributeDescription + ) + assert ( + output_data_manual.Requirements_Attributes_AdditionalInformation + == PROWLER_THREATSCORE_GCP.Requirements[1] + .Attributes[0] + .AdditionalInformation + ) + assert ( + output_data_manual.Requirements_Attributes_LevelOfRisk + == PROWLER_THREATSCORE_GCP.Requirements[1].Attributes[0].LevelOfRisk + ) + assert output_data_manual.Status == "MANUAL" + assert output_data_manual.StatusExtended == "Manual check" + assert output_data_manual.ResourceId == "manual_check" + assert output_data_manual.ResourceName == "Manual check" + assert output_data_manual.CheckId == "manual" + assert not output_data_manual.Muted + + @freeze_time(datetime.now()) + def test_batch_write_data_to_file(self): + mock_file = StringIO() + findings = [ + generate_finding_output(compliance={"ProwlerThreatScore-1.0": "1.1.1"}) + ] + output = ProwlerThreatScoreGCP( + findings, PROWLER_THREATSCORE_GCP, PROWLER_THREATSCORE_GCP_NAME + ) + output._file_descriptor = mock_file + + with patch.object(mock_file, "close", return_value=None): + output.batch_write_data_to_file() + + mock_file.seek(0) + content = mock_file.read() + expected_csv = f"PROVIDER;DESCRIPTION;PROJECTID;LOCATION;ASSESSMENTDATE;REQUIREMENTS_ID;REQUIREMENTS_DESCRIPTION;REQUIREMENTS_ATTRIBUTES_TITLE;REQUIREMENTS_ATTRIBUTES_SECTION;REQUIREMENTS_ATTRIBUTES_SUBSECTION;REQUIREMENTS_ATTRIBUTES_ATTRIBUTEDESCRIPTION;REQUIREMENTS_ATTRIBUTES_ADDITIONALINFORMATION;REQUIREMENTS_ATTRIBUTES_LEVELOFRISK;STATUS;STATUSEXTENDED;RESOURCEID;RESOURCENAME;CHECKID;MUTED\r\naws;Prowler ThreatScore Compliance Framework for GCP ensures that the GCP account is compliant taking into account four main pillars: Identity and Access Management, Attack Surface, Forensic Readiness and Encryption;123456789012;eu-west-1;{datetime.now()};1.1.1;Ensure MFA is enabled for the 'root' user account;MFA enabled for 'root';1. IAM;1.1 Authentication;The root user account holds the highest level of privileges within an AWS account. Enabling Multi-Factor Authentication (MFA) enhances security by adding an additional layer of protection beyond just a username and password. With MFA activated, users must provide their credentials (username and password) along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.;Enabling MFA enhances console security by requiring the authenticating user to both possess a time-sensitive key-generating device and have knowledge of their credentials.;5;PASS;;;;test-check-id;False\r\ngcp;Prowler ThreatScore Compliance Framework for GCP ensures that the GCP account is compliant taking into account four main pillars: Identity and Access Management, Attack Surface, Forensic Readiness and Encryption;;;{datetime.now()};1.1.2;Ensure hardware MFA is enabled for the 'root' user account;CloudTrail logging enabled;1. IAM;1.1 Authentication;The root user account in AWS has the highest level of privileges. Multi-Factor Authentication (MFA) enhances security by adding an extra layer of protection beyond a username and password. When MFA is enabled, users must enter their credentials along with a unique authentication code generated by their AWS MFA device when signing into an AWS website.;A hardware MFA has a smaller attack surface compared to a virtual MFA. Unlike a virtual MFA, which relies on a mobile device that may be vulnerable to malware or compromise, a hardware MFA operates independently, reducing exposure to potential security threats.;3;MANUAL;Manual check;manual_check;Manual check;manual;False\r\n" + + assert content == expected_csv diff --git a/util/generate_compliance_json_from_csv_threatscope.py b/util/generate_compliance_json_from_csv_threatscope.py new file mode 100644 index 0000000000..47865d0c8d --- /dev/null +++ b/util/generate_compliance_json_from_csv_threatscope.py @@ -0,0 +1,36 @@ +import csv +import json +import sys + +# Convert a CSV file following the ThreatScore CSV format into a Prowler Compliance JSON file +# CSV fields: +# Id, Title, Description, Section, SubSection, AttributeDescription, AdditionalInformation, LevelOfRisk, Checks + +# get the CSV filename to convert from +file_name = sys.argv[1] + +# read the CSV file rows and use the column fields to form the Prowler compliance JSON file 'prowler_threatscore_aws.json' +output = {"Framework": "ProwlerThreatScore", "Version": "1.0", "Requirements": []} +with open(file_name, newline="", encoding="utf-8") as f: + reader = csv.reader(f, delimiter=",") + for row in reader: + attribute = { + "Title": row[1], + "Section": row[3], + "SubSection": row[4], + "AttributeDescription": row[5], + "AdditionalInformation": row[6], + "LevelOfRisk": row[7], + } + output["Requirements"].append( + { + "Id": row[0], + "Description": row[2], + "Checks": list(map(str.strip, row[8].split(","))), + "Attributes": [attribute], + } + ) + +# Write the output Prowler compliance JSON file 'prowler_threatscore_aws.json' locally +with open("prowler_threatscore_azure.json", "w", encoding="utf-8") as outfile: + json.dump(output, outfile, indent=4, ensure_ascii=False) diff --git a/util/get_prowler_threatscore_from_generic_output.py b/util/get_prowler_threatscore_from_generic_output.py new file mode 100644 index 0000000000..d3cd53a6b6 --- /dev/null +++ b/util/get_prowler_threatscore_from_generic_output.py @@ -0,0 +1,52 @@ +import csv +import json +import sys + +file_name_output = sys.argv[1] # It is the output CSV file +file_name_compliance = sys.argv[2] # It is the compliance JSON file + + +number_of_findings_per_pillar = {} +score_per_pillar = {} +# Read the compliance JSON file +with open(file_name_compliance, "r") as file: + data = json.load(file) + +# Read the output CSV file +with open(file_name_output, "r") as file: + reader = csv.reader(file, delimiter=";") + headers = next(reader) + if "CHECK_ID" in headers: + check_id_index = headers.index("CHECK_ID") + if "STATUS" in headers: + status_index = headers.index("STATUS") + if "MUTED" in headers: + muted_index = headers.index("MUTED") + for row in reader: + for requirement in data["Requirements"]: + # Take the column that contains the CHECK_ID + if row[check_id_index] in requirement["Checks"]: + if ( + requirement["Attributes"][0]["Section"] + not in number_of_findings_per_pillar.keys() + ): + number_of_findings_per_pillar[ + requirement["Attributes"][0]["Section"] + ] = 0 + if ( + requirement["Attributes"][0]["Section"] + not in score_per_pillar.keys() + ): + score_per_pillar[requirement["Attributes"][0]["Section"]] = 0 + if row[status_index] == "FAIL" and row[muted_index] != "TRUE": + number_of_findings_per_pillar[ + requirement["Attributes"][0]["Section"] + ] += 1 + score_per_pillar[ + requirement["Attributes"][0]["Section"] + ] += requirement["Attributes"][0]["LevelOfRisk"] + +for key, value in number_of_findings_per_pillar.items(): + print("Pillar:", key) + print("Score:", score_per_pillar[key] / value) + print("--------------------------------")