ben.carrasco/prowler
1
0
Fork 0
mirror of https://github.com/prowler-cloud/prowler.git synced 2025-12-19 05:17:47 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat(prowler-threatscore): add Weight field inside req (#7795)

Browse Source 
Co-authored-by: Sergio Garcia <hello@mistercloudsec.com>
This commit is contained in:
Pedro Martín
2025-05-21 12:57:10 +02:00
committed by GitHub
parent 16cd0e4661
commit 65d3fcee4c
22 changed files with 980 additions and 365 deletions
Download Patch File Download Diff File Expand all files Collapse all files

145
dashboard/pages/compliance.py
View File

@@ -651,58 +651,114 @@ def get_table(current_compliance, table):
def get_threatscore_mean_by_pillar(df):
modified_df = df[df["STATUS"] == "FAIL"]
score_per_pillar = {}
max_score_per_pillar = {}
modified_df["REQUIREMENTS_ATTRIBUTES_LEVELOFRISK"] = pd.to_numeric(
modified_df["REQUIREMENTS_ATTRIBUTES_LEVELOFRISK"], errors="coerce"
)
for _, row in df.iterrows():
pillar = (
row["REQUIREMENTS_ATTRIBUTES_SECTION"].split(" - ")[0]
if isinstance(row["REQUIREMENTS_ATTRIBUTES_SECTION"], str)
else "Unknown"
)
pillar_means = (
modified_df.groupby("REQUIREMENTS_ATTRIBUTES_SECTION")[
"REQUIREMENTS_ATTRIBUTES_LEVELOFRISK"
]
.mean()
.round(2)
)
if pillar not in score_per_pillar:
score_per_pillar[pillar] = 0
max_score_per_pillar[pillar] = 0
level_of_risk = pd.to_numeric(
row["REQUIREMENTS_ATTRIBUTES_LEVELOFRISK"], errors="coerce"
)
level_of_risk = 1 if pd.isna(level_of_risk) else level_of_risk
weight = 1
if "REQUIREMENTS_ATTRIBUTES_WEIGHT" in row and not pd.isna(
row["REQUIREMENTS_ATTRIBUTES_WEIGHT"]
):
weight = pd.to_numeric(
row["REQUIREMENTS_ATTRIBUTES_WEIGHT"], errors="coerce"
)
weight = 1 if pd.isna(weight) else weight
max_score_per_pillar[pillar] += level_of_risk * weight
if row["STATUS"] == "PASS":
score_per_pillar[pillar] += level_of_risk * weight
output = []
for pillar, mean in pillar_means.items():
output.append(f"{pillar} - [{mean}]")
for pillar in max_score_per_pillar:
risk_score = 0
if max_score_per_pillar[pillar] > 0:
risk_score = (score_per_pillar[pillar] / max_score_per_pillar[pillar]) * 100
output.append(f"{pillar} - [{risk_score:.1f}%]")
for value in output:
if value.split(" - ")[0] in df["REQUIREMENTS_ATTRIBUTES_SECTION"].values:
base_pillar = value.split(" - ")[0]
if base_pillar in df["REQUIREMENTS_ATTRIBUTES_SECTION"].values:
df.loc[
df["REQUIREMENTS_ATTRIBUTES_SECTION"] == value.split(" - ")[0],
df["REQUIREMENTS_ATTRIBUTES_SECTION"] == base_pillar,
"REQUIREMENTS_ATTRIBUTES_SECTION",
] = value
return df
def get_table_prowler_threatscore(df):
df = df[df["STATUS"] == "FAIL"]
score_per_pillar = {}
max_score_per_pillar = {}
pillars = {}
# Delete " - " from the column REQUIREMENTS_ATTRIBUTES_SECTION
df["REQUIREMENTS_ATTRIBUTES_SECTION"] = (
df["REQUIREMENTS_ATTRIBUTES_SECTION"].str.split(" - ").str[0]
)
df_copy = df.copy()
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",
}
for _, row in df_copy.iterrows():
pillar = (
row["REQUIREMENTS_ATTRIBUTES_SECTION"].split(" - ")[0]
if isinstance(row["REQUIREMENTS_ATTRIBUTES_SECTION"], str)
else "Unknown"
)
)
if pillar not in pillars:
pillars[pillar] = {"FAIL": 0, "PASS": 0, "MUTED": 0}
score_per_pillar[pillar] = 0
max_score_per_pillar[pillar] = 0
level_of_risk = pd.to_numeric(
row["REQUIREMENTS_ATTRIBUTES_LEVELOFRISK"], errors="coerce"
)
level_of_risk = 1 if pd.isna(level_of_risk) else level_of_risk
weight = 1
if "REQUIREMENTS_ATTRIBUTES_WEIGHT" in row and not pd.isna(
row["REQUIREMENTS_ATTRIBUTES_WEIGHT"]
):
weight = pd.to_numeric(
row["REQUIREMENTS_ATTRIBUTES_WEIGHT"], errors="coerce"
)
weight = 1 if pd.isna(weight) else weight
max_score_per_pillar[pillar] += level_of_risk * weight
if row["STATUS"] == "PASS":
pillars[pillar]["PASS"] += 1
score_per_pillar[pillar] += level_of_risk * weight
elif row["STATUS"] == "FAIL":
pillars[pillar]["FAIL"] += 1
if "MUTED" in row and row["MUTED"] == "True":
pillars[pillar]["MUTED"] += 1
result_df = []
for pillar in pillars.keys():
risk_score = 0
if max_score_per_pillar[pillar] > 0:
risk_score = (score_per_pillar[pillar] / max_score_per_pillar[pillar]) * 100
result_df.append({"Pillar": pillar, "Score": risk_score})
score_df = pd.DataFrame(result_df)
score_df = score_df.sort_values("Score", ascending=True)
fig = px.bar(
score_df,
@@ -710,22 +766,25 @@ def get_table_prowler_threatscore(df):
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"},
"#f4d44d",
"#45cc6e",
],
labels={"Score": "Risk Score (%)", "Pillar": "Section"},
height=400,
text="Score",
)
fig.update_traces(texttemplate="%{text:.1f}%", textposition="outside")
fig.update_layout(
xaxis_title="Pillar",
yaxis_title="Level of Risk",
yaxis_title="Risk Score (%)",
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"),
coloraxis_colorbar=dict(title="Risk %"),
yaxis=dict(range=[0, 110]),
)
return dcc.Graph(

1
prowler/CHANGELOG.md
View File

@@ -7,6 +7,7 @@ All notable changes to the **Prowler SDK** are documented in this file.
### Added
- Add CIS 1.11 compliance framework for Kubernetes. [(#7790)](https://github.com/prowler-cloud/prowler/pull/7790)
- Support `HTTPS_PROXY` and `K8S_SKIP_TLS_VERIFY` in Kubernetes. [(#7720)](https://github.com/prowler-cloud/prowler/pull/7720)
- Add Weight for Prowler ThreatScore scoring. [(7795)](https://github.com/prowler-cloud/prowler/pull/7795)
- Add new check `entra_users_mfa_capable` for M365 provider. [(#7734)](https://github.com/prowler-cloud/prowler/pull/7734)
- Add new check `admincenter_organization_customer_lockbox_enabled` for M365 provider. [(#7732)](https://github.com/prowler-cloud/prowler/pull/7732)
- Add new check `admincenter_external_calendar_sharing_disabled` for M365 provider. [(#7733)](https://github.com/prowler-cloud/prowler/pull/7733)

318
prowler/compliance/aws/prowler_threatscore_aws.json
View File

@@ -17,7 +17,8 @@
"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
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -34,7 +35,8 @@
"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
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -51,7 +53,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -68,7 +71,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -85,7 +89,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -102,7 +107,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -119,7 +125,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -136,7 +143,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -153,7 +161,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -171,7 +180,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -188,7 +198,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -205,7 +216,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -222,7 +234,8 @@
"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
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -239,7 +252,8 @@
"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
"LevelOfRisk": 1,
"Weight": 1
}
]
},
@@ -256,7 +270,8 @@
"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
"LevelOfRisk": 1,
"Weight": 1
}
]
},
@@ -274,7 +289,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -291,7 +307,8 @@
"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
"LevelOfRisk": 1,
"Weight": 1
}
]
},
@@ -308,7 +325,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -325,7 +343,8 @@
"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": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -342,7 +361,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -359,7 +379,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -376,7 +397,8 @@
"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
"LevelOfRisk": 1,
"Weight": 1
}
]
},
@@ -393,7 +415,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -410,7 +433,8 @@
"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
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -427,7 +451,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -444,7 +469,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -461,7 +487,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -478,7 +505,8 @@
"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
"LevelOfRisk": 1,
"Weight": 1
}
]
},
@@ -495,7 +523,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -512,7 +541,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -531,7 +561,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -550,7 +581,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -567,7 +599,8 @@
"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
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -584,7 +617,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -601,7 +635,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -618,7 +653,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -635,7 +671,8 @@
"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
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -652,7 +689,8 @@
"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
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -669,7 +707,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -686,7 +725,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -703,7 +743,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -720,7 +761,8 @@
"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": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -737,7 +779,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -754,7 +797,8 @@
"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
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -771,7 +815,8 @@
"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": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -788,7 +833,8 @@
"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": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -805,7 +851,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -838,7 +885,8 @@
"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": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -869,7 +917,8 @@
"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": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -886,7 +935,8 @@
"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": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -903,7 +953,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -920,7 +971,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -937,7 +989,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -954,7 +1007,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -971,7 +1025,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -988,7 +1043,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1005,7 +1061,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1022,7 +1079,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1039,7 +1097,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1056,7 +1115,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1073,7 +1133,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1090,7 +1151,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1107,7 +1169,8 @@
"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": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -1124,7 +1187,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1141,7 +1205,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1158,7 +1223,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1175,7 +1241,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1192,7 +1259,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1209,7 +1277,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1226,7 +1295,8 @@
"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": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -1243,7 +1313,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1260,7 +1331,8 @@
"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
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -1277,7 +1349,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1294,7 +1367,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1311,7 +1385,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1328,7 +1403,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1345,7 +1421,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1362,7 +1439,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1379,7 +1457,8 @@
"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": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -1396,7 +1475,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1413,7 +1493,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1430,7 +1511,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1447,7 +1529,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1464,7 +1547,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1481,7 +1565,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1498,7 +1583,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1515,7 +1601,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1532,7 +1619,8 @@
"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
"LevelOfRisk": 1,
"Weight": 1
}
]
},
@@ -1549,7 +1637,8 @@
"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
"LevelOfRisk": 1,
"Weight": 1
}
]
},
@@ -1566,7 +1655,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1583,7 +1673,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1600,7 +1691,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1617,7 +1709,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1634,7 +1727,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1651,7 +1745,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1668,7 +1763,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1685,7 +1781,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1702,7 +1799,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1719,7 +1817,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1736,7 +1835,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1753,7 +1853,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1770,7 +1871,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1787,7 +1889,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1804,7 +1907,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1821,7 +1925,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1838,7 +1943,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
}

231
prowler/compliance/azure/prowler_threatscore_azure.json
View File

@@ -17,7 +17,8 @@
"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
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -34,7 +35,8 @@
"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
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -51,7 +53,8 @@
"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
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -68,7 +71,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -85,7 +89,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -102,7 +107,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -119,7 +125,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -136,7 +143,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -153,7 +161,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -170,7 +179,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -187,7 +197,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -204,7 +215,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -221,7 +233,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -238,7 +251,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -255,7 +269,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -272,7 +287,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -289,7 +305,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -306,7 +323,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -323,7 +341,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -340,7 +359,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -357,7 +377,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -374,7 +395,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -391,7 +413,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -408,7 +431,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -425,7 +449,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -442,7 +467,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -459,7 +485,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -476,7 +503,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -493,7 +521,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -510,7 +539,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -527,7 +557,8 @@
"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": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -544,7 +575,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -561,7 +593,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -578,7 +611,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -595,7 +629,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -612,7 +647,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -629,7 +665,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -646,7 +683,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -663,7 +701,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -680,7 +719,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -697,7 +737,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -714,7 +755,8 @@
"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": 1
"LevelOfRisk": 1,
"Weight": 1
}
]
},
@@ -731,7 +773,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -748,7 +791,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -765,7 +809,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -782,7 +827,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -799,7 +845,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -816,7 +863,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -833,7 +881,8 @@
"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
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -850,7 +899,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -867,7 +917,8 @@
"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": 1
"LevelOfRisk": 1,
"Weight": 1
}
]
},
@@ -884,7 +935,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -901,7 +953,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -918,7 +971,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -935,7 +989,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -952,7 +1007,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -969,7 +1025,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -986,7 +1043,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1003,7 +1061,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1020,7 +1079,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1037,7 +1097,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1054,7 +1115,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1071,7 +1133,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1088,7 +1151,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1105,7 +1169,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1122,7 +1187,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1139,7 +1205,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1156,7 +1223,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1173,7 +1241,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1190,7 +1259,8 @@
"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
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -1207,7 +1277,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1224,7 +1295,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1241,7 +1313,8 @@
"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": 1
"LevelOfRisk": 1,
"Weight": 1
}
]
},
@@ -1258,7 +1331,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1275,7 +1349,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1292,7 +1367,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -1309,7 +1385,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
}

171
prowler/compliance/gcp/prowler_threatscore_gcp.json
View File

@@ -17,7 +17,8 @@
"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": 1
"LevelOfRisk": 1,
"Weight": 1
}
]
},
@@ -34,7 +35,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -51,7 +53,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -68,7 +71,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -85,7 +89,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -102,7 +107,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -119,7 +125,8 @@
"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": 1
"LevelOfRisk": 1,
"Weight": 1
}
]
},
@@ -136,7 +143,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -153,7 +161,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -170,7 +179,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -187,7 +197,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -204,7 +215,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -221,7 +233,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -238,7 +251,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -255,7 +269,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -272,7 +287,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -289,7 +305,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -306,7 +323,8 @@
"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
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -323,7 +341,8 @@
"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
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -340,7 +359,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -357,7 +377,8 @@
"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
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -374,7 +395,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -391,7 +413,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -408,7 +431,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -425,7 +449,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -442,7 +467,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -459,7 +485,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -476,7 +503,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -493,7 +521,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -510,7 +539,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -527,7 +557,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -544,7 +575,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -561,7 +593,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -578,7 +611,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -595,7 +629,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -612,7 +647,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -629,7 +665,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -646,7 +683,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -663,7 +701,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -680,7 +719,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -697,7 +737,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -714,7 +755,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -731,7 +773,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -748,7 +791,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -765,7 +809,8 @@
"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
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -782,7 +827,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -799,7 +845,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -816,7 +863,8 @@
"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
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -833,7 +881,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -850,7 +899,8 @@
"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": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -867,7 +917,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -884,7 +935,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -901,7 +953,8 @@
"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": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -918,7 +971,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -935,7 +989,8 @@
"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
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -952,7 +1007,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -969,7 +1025,8 @@
"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": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
}

189
prowler/compliance/m365/prowler_threatscore_m365.json
View File

@@ -17,7 +17,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "Microsoft cloud-only accounts are governed by a built-in password policy that cannot be customized. The only configurable options are the password expiration period and whether password expiration is enabled at all.",
"AdditionalInformation": "Modern security guidance from organizations like NIST and Microsoft recommends against forcing regular password changes unless there is a known compromise or the user has forgotten the password. Arbitrary password expiration policies can lead to weaker password practices, such as predictable patterns or reused credentials. This is especially relevant even in single-factor (password-only) scenarios. When combined with strong security measures like Multi-Factor Authentication (MFA) and Entra ID password protection, the need for periodic password changes becomes less critical. As such, it’s more effective to focus on strengthening overall authentication practices rather than enforcing frequent password resets.",
"LevelOfRisk": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -34,7 +35,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "Multifactor Authentication (MFA) enhances account security by requiring users to provide at least two forms of identity verification during sign-in—such as a password and a one-time code from a mobile device, biometric scan, or authentication app. It is critical to ensure that all users in administrator roles have MFA enabled to protect privileged access.",
"AdditionalInformation": "MFA significantly reduces the risk of unauthorized access by requiring attackers to compromise multiple independent authentication factors. For administrative accounts—often targeted due to their elevated privileges—this additional layer of security is essential. Enforcing MFA for admins helps ensure that only authorized individuals can access sensitive systems and configurations, thereby strengthening the overall security posture of the organization.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -51,7 +53,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "Enable Multifactor Authentication (MFA) for all users in the Microsoft 365 tenant to strengthen identity security. Once enabled, users will be prompted to verify their identity using a second factor during sign-in. Common second factors include a one-time code sent via SMS or generated through an authentication app such as Microsoft Authenticator.",
"AdditionalInformation": "MFA adds a critical layer of protection by requiring users to provide two or more independent forms of authentication before access is granted. This significantly reduces the likelihood of unauthorized access, as an attacker would need to compromise both the primary credentials and the second authentication factor. Enabling MFA across all user accounts helps protect the organization from phishing, credential theft, and other identity-based threats.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -68,7 +71,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "Microsoft Entra ID supports a variety of authentication and authorization protocols, including legacy authentication methods. Legacy authentication typically refers to Basic Authentication, which prompts users to submit a username and password without support for modern security features like Multifactor Authentication (MFA). Several messaging and connection protocols fall under legacy authentication, including: • Authenticated SMTP – Sends authenticated email messages. • Autodiscover – Helps Outlook and Exchange ActiveSync (EAS) clients locate mailboxes. • Exchange ActiveSync (EAS) – Connects mobile devices to Exchange Online. • Exchange Online PowerShell – Requires the Exchange Online PowerShell Module when Basic Auth is blocked. • Exchange Web Services (EWS) – Used by Outlook, Outlook for Mac, and third-party applications. • IMAP4 and POP3 – Used by legacy email clients. • MAPI over HTTP (MAPI/HTTP) – Primary protocol for Outlook 2010 SP2 and newer. • Offline Address Book (OAB) – Downloads address lists for Outlook. • Outlook Anywhere (RPC over HTTP) – Legacy access method for Outlook. • Reporting Web Services – Retrieves reporting data from Exchange Online.•Universal Outlook – Used by the Windows 10 Mail and Calendar app. • Other clients – Protocols identified as using legacy authentication patterns.",
"AdditionalInformation": "Legacy authentication protocols do not support multifactor authentication, making them a common attack vector for credential theft and brute-force attacks. Blocking legacy authentication significantly reduces the organization’s attack surface and helps enforce modern, more secure sign-in methods that support MFA.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -85,7 +89,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "Authentication Strength is a Conditional Access (CA) control in Microsoft Entra ID that allows administrators to define which authentication methods are permitted for accessing specific resources. This enables a tailored approach to security—stronger methods can be enforced for sensitive assets, while less secure methods may be acceptable for lower-risk scenarios. Microsoft provides three built-in authentication strength levels: • MFA Strength • Passwordless MFA Strength • Phishing-resistant MFA Strength It is recommended that all users in administrator roles are protected by a Conditional Access policy that enforces Phishing-resistant MFA Strength. Administrators can meet this requirement by registering and using one of the following phishing-resistant authentication methods: • FIDO2 Security Key • Windows Hello for Business • Certificate-based Authentication (CBA) Note: Configuration steps for these methods (e.g., setting up FIDO2 keys) are not covered here but are available in Microsoft’s documentation. The Conditional Access policy only enforces that at least one of these methods is used. Warning: Ensure that administrators are pre-registered for one of the supported strong authentication methods before enforcing the policy. As also recommended elsewhere in the CIS Benchmark, a break-glass account should be excluded from this policy to maintain emergency access.",
"AdditionalInformation": "As MFA adoption increases, so does the sophistication of attacks designed to bypass it. Phishing-resistant authentication methods are more secure because they eliminate passwords from the authentication process. These methods rely on strong public/private key cryptography and ensure that authentication can only occur between trusted devices and providers—preventing login attempts from fake or phishing websites.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -102,7 +107,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "Conditional Access (CA) policies can be configured to enforce access controls based on whether a device is compliant or Microsoft Entra hybrid joined. These conditions allow organizations to distinguish between managed and unmanaged devices, enabling more granular enforcement of authentication policies. • The Require device to be marked as compliant control ensures that devices meet the compliance standards defined in Intune compliance policies. Devices must first be enrolled in Intune Mobile Device Management (MDM) before these policies can be evaluated. • The Require Microsoft Entra hybrid joined device control applies to devices synchronized from an on-premises Active Directory environment, marking them as trusted within the hybrid identity model. When both conditions are included in the same Conditional Access policy, the evaluation functions as an OR logic—only one of the two conditions needs to be met for the user to authenticate successfully from a device. Recommended configuration: • Require device to be marked as compliant • Require Microsoft Entra hybrid joined device • Require one of the selected controls",
"AdditionalInformation": "Managed devices are generally more secure due to enforced configurations such as Group Policy, mobile device compliance policies, endpoint detection and response (EDR), managed patching, and centralized alerting. Limiting access to only compliant or hybrid joined devices ensures that users are authenticating from secure environments. This policy helps mitigate the risk of compromised credentials by requiring attackers to first obtain access to a trusted device. When combined with additional CA controls—such as multi-factor authentication—it adds a further barrier to unauthorized access and strengthens the organization’s overall security posture.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -119,7 +125,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "Conditional Access (CA) policies can be used to restrict the registration of multi-factor authentication (MFA) methods based on a device’s compliance status or whether it is Microsoft Entra hybrid joined. This allows organizations to enforce that only managed devices are used when users register security information.• Require device to be marked as compliant enforces that the device meets all conditions defined in Intune compliance policies. Devices must be enrolled in Intune Mobile Device Management (MDM) for this to apply. • Require Microsoft Entra hybrid joined device ensures the device has been synchronized from an on-premises Active Directory, marking it as trusted within the hybrid identity environment. When both controls are included in a Conditional Access policy for MFA registration, they operate with OR logic—only one of the conditions must be satisfied for the user to proceed. Recommended configuration: Restrict the “Register security information” operation to devices that are either compliant or Microsoft Entra hybrid joined.",
"AdditionalInformation": "Restricting MFA registration to trusted, managed devices significantly reduces the risk of attackers using stolen credentials to set up fraudulent authentication methods. Accounts that exist but are not yet registered for MFA are particularly vulnerable to takeover. This policy ensures that security information is registered only from secured, policy-enforced endpoints—which often include additional layers of protection such as endpoint detection, encryption, and monitoring—thereby reducing the attack surface and strengthening the organization’s identity security posture.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -136,7 +143,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "Modern authentication in Microsoft 365 enables advanced authentication capabilities such as multifactor authentication (MFA), smart card support, certificate-based authentication (CBA), and integration with third-party SAML identity providers. It replaces legacy authentication protocols with more secure, token-based authentication methods. It is recommended to enforce modern authentication for SharePoint applications to ensure secure access.",
"AdditionalInformation": "If SharePoint applications are allowed to use basic authentication, they may bypass strong authentication controls such as MFA, exposing the environment to potential compromise. Enforcing modern authentication ensures that all sessions between users, applications, and SharePoint utilize robust, policy-enforced authentication methods—significantly reducing the risk of credential theft and unauthorized access.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -153,7 +161,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "SharePoint Online allows users to share files, folders, and entire site collections both internally and externally. With appropriate permissions, internal users can extend access to external collaborators, enabling seamless cross-organizational collaboration.",
"AdditionalInformation": "While external sharing supports productivity and collaboration, it’s essential that owners of files, folders, or site collections retain control over what content is shared and with whom. This helps prevent unauthorized data disclosure and ensures that sensitive information is only accessible to intended recipients. Proper sharing governance empowers data owners to make informed decisions and reinforces accountability across the organization.",
"LevelOfRisk": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -170,7 +179,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "The “Multi-Factor Authentication (MFA) Status” setting determines whether users are required to authenticate using a second factor beyond their password. For privileged users—those with administrative roles or elevated permissions—this setting should be set to “Enabled” to ensure that MFA is enforced whenever they sign in.",
"AdditionalInformation": "Privileged accounts have access to critical systems, sensitive data, and administrative functions that, if compromised, could lead to significant security breaches. Enforcing MFA for all privileged users greatly reduces the risk of unauthorized access by requiring attackers to compromise two or more independent authentication factors. MFA is one of the most effective defenses against phishing, credential theft, and brute-force attacks, making it a foundational control for protecting administrative accounts in any secure identity and access management strategy.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -187,7 +197,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "The “Multi-Factor Authentication (MFA) Status” setting determines whether users must verify their identity using a second factor in addition to their password. For non-privileged users—those without administrative or elevated permissions—it is recommended that MFA is enabled across the entire user base to provide comprehensive protection against identity-based attacks.",
"AdditionalInformation": "While non-privileged users may not have administrative access, they still have access to email, internal systems, and potentially sensitive business data. These accounts are often targeted in phishing campaigns, credential stuffing attacks, and social engineering tactics to gain an initial foothold in the organization. Enforcing MFA for all users significantly reduces the likelihood of account compromise by requiring a second form of verification, such as a mobile app, hardware token, or one-time passcode. This broad protection is essential in a Zero Trust security model and ensures that every account—regardless of privilege—is secured against unauthorized access.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -204,7 +215,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "The External Callouts feature in Exchange Online introduces a native visual indicator for emails originating from outside the organization. When enabled, this feature displays a localized “External” tag within supported Outlook clients, along with additional user interface elements at the top of the message reading pane. These enhancements help users easily identify and verify the actual sender’s email address, providing critical context when evaluating incoming messages. The feature is enabled via PowerShell using the Set-ExternalInOutlook cmdlet, and typically becomes visible to end users within 24–48 hours, provided their Outlook client version supports the functionality. Note: While Exchange administrators have historically used mail flow rules to prepend “[External]” or similar text to subject lines, this method is less reliable and may not consistently apply across all message types or clients. The CIS Benchmark recommends enabling the native External tagging feature for a more consistent and secure user experience.",
"AdditionalInformation": "Tagging emails from external senders increases user awareness and vigilance, enabling recipients to recognize messages that originate outside the organization’s trusted environment. This visual cue acts as a simple but effective layer of defense, encouraging users to treat unexpected or suspicious emails with caution—especially those that may be phishing attempts, impersonation attacks, or social engineering lures. By clearly marking external messages, organizations enhance their users’ ability to make informed security decisions, reducing the likelihood of credential compromise, malware infection, or inadvertent data disclosure.",
"LevelOfRisk": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -221,7 +233,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "Modern authentication in Microsoft 365 enables advanced authentication capabilities such as multi-factor authentication (MFA), smart card-based login, certificate-based authentication (CBA), and integration with third-party SAML identity providers. When enabled for Exchange Online, clients like Outlook 2016 and Outlook 2013 utilize modern authentication protocols (such as OAuth 2.0) to securely connect to Microsoft 365 mailboxes. If modern authentication is disabled, these clients fall back to basic authentication, a legacy protocol that transmits credentials in plaintext and lacks support for MFA. Newer clients—including Outlook for Mac 2016, Outlook Mobile, and all Microsoft 365 Apps for Enterprise versions of Outlook—are built to use modern authentication by default.",
"AdditionalInformation": "Allowing basic authentication significantly weakens the security posture of an organization. It bypasses modern controls like multi-factor authentication, exposing user credentials to a higher risk of compromise through phishing, brute-force attacks, or session hijacking. By enabling modern authentication in Exchange Online, organizations enforce the use of strong, token-based authentication methods that are resistant to credential theft and session replay. This is critical for protecting sensitive email data and ensuring secure communication between user devices and Microsoft 365 services. Enabling modern authentication also supports compliance mandates and zero-trust principles, making it a foundational step in securing user identities and email infrastructure.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -238,7 +251,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "This policy setting in Microsoft Teams controls who is allowed to bypass the meeting lobby and directly join a meeting. When properly configured, only explicitly invited attendees—either those directly invited by the organizer or individuals to whom the invitation was intentionally forwarded—can skip the lobby and enter the meeting. All other participants, including anonymous users or those with access to the meeting link but not explicitly invited, must wait in the lobby for approval by the meeting organizer or a designated participant.",
"AdditionalInformation": "For meetings involving sensitive, confidential, or regulated information, it is essential to tightly control participant access. Requiring all non-invited individuals to wait in the lobby allows the organizer to review and manually admit attendees, thereby preventing unauthorized access or accidental exposure of sensitive content. Additionally, this setting prevents misuse of the meeting link by anonymous or unintended users, such as initiating unauthorized meetings outside scheduled times. Even organizations that do not regularly operate in high-security (Level 2) environments but occasionally handle sensitive data should consider enabling this policy to reinforce data protection and meeting integrity. By limiting automatic entry to only verified, intended participants, this control supports secure collaboration, reduces risk of information leakage, and enhances confidence in Microsoft Teams as a platform for sensitive communications.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -255,7 +269,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "This policy setting in Microsoft Teams determines whether anonymous participants can start a meeting before a verified user from the organization or a trusted external organization has joined. When this setting is enabled, anonymous users and dial-in callers must wait in the meeting lobby until the meeting is initiated by an authenticated participant. Anonymous participants are defined as: • Users not signed in with a work or school account • Participants from non-trusted organizations, based on external access configuration • Individuals from organizations without mutual trust relationships Note: This setting only applies when the “Who can bypass the lobby” policy is set to Everyone. If the broader setting “Anonymous users can join a meeting” is disabled at the organizational level, this policy applies only to dial-in callers.",
"AdditionalInformation": "Disallowing anonymous participants from starting meetings helps mitigate the risk of meeting abuse, such as spamming, hijacking, or unauthorized use of Teams meetings for unintended purposes. Anonymous users pose a higher risk because their identities cannot be verified, and they are not subject to organizational controls or compliance policies. Requiring an authenticated user to start the meeting ensures that someone with verified access and accountability is present before the session begins. This adds a layer of security and governance, especially in meetings that could involve sensitive discussions or are exposed to a wide range of external participants. Enforcing this policy supports a secure and controlled meeting environment and aligns with best practices for preventing unauthorized or disruptive activity in collaborative platforms.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -272,7 +287,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "This policy setting in Microsoft Teams defines who can bypass the meeting lobby and join a meeting directly, versus who must wait in the lobby until admitted by a meeting organizer, co-organizer, or designated presenter. Options include allowing access to everyone, people in your organization, trusted external organizations, or only invited users.",
"AdditionalInformation": "Restricting direct access to meetings—particularly those that involve sensitive, confidential, or regulated information—ensures that only authorized and expected attendees can participate. Requiring participants to wait in the lobby gives meeting organizers the opportunity to vet and approve each attendee before admitting them. This policy also helps prevent unauthorized access through forwarded meeting links and reduces the risk of anonymous users joining meetings at unscheduled times, which can lead to disruptions or even security breaches. Enforcing lobby controls aligns with zero trust principles and is a best practice for maintaining the integrity and confidentiality of Teams meetings.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -289,7 +305,8 @@
"SubSection": "1.1 Authentication",
"AttributeDescription": "This policy setting in Microsoft Teams determines whether dial-in participants—users who join meetings by phone—can bypass the lobby and join directly, or if they must wait in the lobby until admitted by a meeting organizer, co-organizer, or presenter.",
"AdditionalInformation": "Dial-in participants typically cannot be authenticated in the same way as users joining via Teams apps or web clients, making it more difficult to verify their identity. For meetings that may involve sensitive, confidential, or regulated information, it is essential that the meeting organizer has the opportunity to manually vet and admit these participants.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -306,7 +323,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "Microsoft 365 Groups serve as the foundation for collaboration across Microsoft 365, providing shared resources (e.g., Outlook inbox, SharePoint site, Teams workspace) to group members. While various group types exist, this recommendation specifically addresses Microsoft 365 Groups. By default, when a Microsoft 365 Group is created via the admin panel, its privacy setting is set to “Public”, meaning anyone in the organization can access its content unless the setting is manually changed.",
"AdditionalInformation": "To protect sensitive organizational data, it’s important to ensure that only authorized and managed public groups exist. Public groups expose their content to all users in the organization through several access paths: • Users can add themselves to a public group using the Azure portal. • Users can request access via the Access Panel’s Groups app—this sends a request to the group owner but still grants immediate access. • Users may discover and directly access the associated SharePoint site via a guessable or easily discoverable URL.While admins are notified when Azure Portal access is used, other methods may not generate alerts. If group privacy settings are not properly managed, sensitive data could be inadvertently exposed. For this reason, privacy settings should be reviewed and adjusted to Private by default unless a public setting is explicitly required and approved.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -323,7 +341,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "A dynamic group in Microsoft Entra ID automatically manages group membership based on user attributes such as userType, department, or country/region. Administrators can define rules to ensure that users meeting specific criteria are added to—or removed from—a group without manual intervention. The recommended configuration is to create a dynamic group that specifically includes guest accounts.",
"AdditionalInformation": "Dynamic groups streamline user management by automating group assignments. By including guest users in a dynamic group, organizations can consistently apply existing Conditional Access policies, access controls, and other security measures. This ensures that new guest accounts are governed by the same security standards as existing ones, reducing the risk of misconfiguration or oversight.",
"LevelOfRisk": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -340,7 +359,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "The admin consent workflow provides a secure and controlled process for granting access to applications that require administrator approval. When a user attempts to access an application but lacks permission to grant consent, they can submit a request for review. This request is sent via email to designated administrators, who act as reviewers. Once a decision is made, the user is notified of the outcome.",
"AdditionalInformation": "The admin consent workflow (Preview) enhances security by ensuring that access to sensitive applications is reviewed and approved by authorized administrators. It prevents users from unintentionally granting permissions to potentially risky applications while maintaining a clear approval process with full visibility and accountability.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -357,7 +377,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "Microsoft Entra ID Protection uses user risk policies to evaluate the likelihood that a user account has been compromised. These policies assign a risk level (low, medium, or high) based on detected anomalies, such as unfamiliar sign-ins, leaked credentials, or atypical behavior. Note: While Entra ID Protection includes built-in user risk policies, Microsoft strongly recommends implementing risk-based Conditional Access (CA) policies instead of relying on the older, legacy policy model. The modern CA approach offers several key advantages:• Access to enhanced diagnostic and troubleshooting data • Integration with report-only mode for safe testing • Support for automation via Microsoft Graph API • Greater flexibility through advanced Conditional Access attributes, such as sign-in frequency and session controls",
"AdditionalInformation": "Enabling user risk policies through Conditional Access allows organizations to automatically respond to suspected account compromise by enforcing real-time controls—such as blocking access or requiring secure reauthentication. This proactive approach enhances the organization’s ability to detect and mitigate identity-based threats before they escalate.",
"LevelOfRisk": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -374,7 +395,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "Microsoft Entra ID Protection evaluates sign-in risk by detecting potentially suspicious sign-in attempts—both in real time and through offline analysis. A risky sign-in indicates that the attempt may not have been performed by the legitimate account owner, based on signals such as unusual location, device anomalies, or unfamiliar sign-in behavior. Note: Although Microsoft Entra ID Protection includes built-in sign-in risk policies, it is strongly recommended to implement risk-based policies using Conditional Access instead of relying on legacy risk policies. The Conditional Access method provides several key advantages: • Access to enhanced diagnostic and investigation data • Ability to test with report-only mode • Integration with Microsoft Graph API for automation and management • Use of additional CA attributes such as sign-in frequency and session controls",
"AdditionalInformation": "Enabling a sign-in risk Conditional Access policy allows organizations to automatically challenge suspicious sign-ins with multi-factor authentication (MFA). This reduces the likelihood of unauthorized access by requiring an additional verification step whenever unusual activity is detected, strengthening identity protection and reducing the risk of account compromise.",
"LevelOfRisk": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -391,7 +413,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "External sharing settings in Microsoft 365 govern how content is shared outside the organization. While each SharePoint site can have its own sharing configuration, it must be equal to or more restrictive than the organization-wide setting. The recommended configuration is “New and existing guests” or a more restrictive option. This setting requires external users to either sign in with a Microsoft 365 work or school account, a personal Microsoft account, or verify their identity using a one-time passcode. Users can share content with existing guests in the directory or invite new guests, who will be added to the directory upon sign-in.",
"AdditionalInformation": "Requiring guest authentication ensures that external users are registered and identifiable within the organization’s directory. This allows administrators to apply governance controls—such as Conditional Access policies, group-based restrictions, and activity monitoring—to external identities. By enforcing authenticated sharing, organizations maintain visibility and control over externally shared resources, reducing the risk of unauthorized data access and supporting compliance with security and privacy policies.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -408,7 +431,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "Organizations can control how documents are shared externally by configuring domain-based restrictions. This can be done by either blocking specific external domains or allowing sharing only with a defined list of trusted domains. These settings apply to services like SharePoint and OneDrive to help manage external collaboration securely.",
"AdditionalInformation": "Restricting document sharing to approved domains reduces the risk of accidental or malicious data exposure. Attackers may attempt to exfiltrate sensitive information by sharing it with external entities. By limiting sharing to trusted domains, organizations minimize their external attack surface and maintain greater control over data flow.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -425,7 +449,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "Anti-spam protection in Exchange Online leverages configurable policies to reduce the volume of unwanted emails—such as junk, bulk, and phishing messages—received by users. These policies include several configurable lists that influence how email from specific sources is treated:• Allowed Senders List • Allowed Domains List • Blocked Senders List • Blocked Domains List While these features offer flexibility, it is strongly recommended not to define any entries in the Allowed Domains List in a production environment.",
"AdditionalInformation": "When a sender or domain is added to the Allowed Domains List, their messages bypass key security checks—including spam filtering and authentication mechanisms like SPF, DKIM, and DMARC—unless flagged as containing malware or high-confidence phishing. This introduces a significant security risk, as attackers may exploit these exceptions to deliver malicious emails directly to users’ inboxes. The risk is especially high when common or widely used domains are allow-listed, as these are frequent targets for spoofing attempts. Moreover, Microsoft’s official guidance clearly states that allowed domains should only be used for testing purposes, not for general use in production environments. To maintain a strong email security posture, organizations should avoid defining Allowed Domains and instead rely on more controlled methods such as block lists, quarantine policies, or targeted safe sender configurations for trusted entities.",
"LevelOfRisk": 1
"LevelOfRisk": 1,
"Weight": 1
}
]
},
@@ -443,7 +468,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "Exchange Online provides multiple mechanisms to manage and control the flow of outbound email messages, helping organizations prevent unauthorized data exfiltration. These mechanisms include: • Remote Domain Settings • Transport Rules • Anti-Spam Outbound Policies These tools work in tandem to control and monitor various email forwarding methods that users or attackers may exploit, such as: • Inbox rules configured in Outlook • Automatic forwarding via Out of Office (OOF) rules • Forwarding settings in Outlook Web Access (OWA) using ForwardingSmtpAddress • Admin-defined forwarding in the Exchange Admin Center (EAC) using ForwardingAddress • Automated forwarding using Power Automate / Microsoft Flow To effectively reduce the risk of unauthorized data leaks, organizations should implement both a Transport Rule and an Outbound Anti-Spam Policy to block automatic mail forwarding. Note: If any exclusions are required (e.g., for trusted third-party systems or compliance tools), they should be strictly defined and approved in accordance with organizational policy.",
"AdditionalInformation": "",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -460,7 +486,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "Mail flow rules (also known as transport rules) in Exchange Online allow administrators to inspect, modify, or block email messages as they pass through the organization. These rules can be configured based on a wide range of conditions—such as sender, recipient, subject content, or attachment type—and can enforce actions including message redirection, header modification, or delivery rejection. While transport rules offer powerful control over email behavior, they must be implemented with caution—particularly when it comes to whitelisting domains or bypassing standard filtering mechanisms.",
"AdditionalInformation": "Whitelisting external domains through transport rules can disable critical security checks such as anti-malware scanning, phishing detection, and sender authentication (e.g., SPF, DKIM, DMARC). If a trusted domain is later compromised—or was malicious from the start—this bypass can allow attackers to deliver malicious content directly to user inboxes without scrutiny. By avoiding broad or permanent domain whitelisting in transport rules, organizations preserve the integrity of their email filtering and reduce the risk of successful phishing campaigns, malware delivery, or data exfiltration originating from seemingly trusted sources. Transport rules should be reviewed regularly, and any exceptions must be justified, narrowly scoped, and documented according to organizational policy.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -477,7 +504,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "MailTips are real-time, context-aware notifications displayed to users as they compose email messages in Outlook. These tips are generated by Exchange while a message is being drafted and are based on an analysis of the email’s content and recipient list. If Exchange detects potential issues—such as the message being sent to a large distribution group, an external recipient, or someone who is out of office—it presents the user with a MailTip alert before the message is sent.This proactive feedback helps users avoid common issues like sending sensitive information to unintended recipients, triggering non-delivery reports (NDRs), or violating communication policies.",
"AdditionalInformation": "Enabling MailTips provides valuable visual cues that promote user awareness and responsible communication. For example, users are warned when they are sending emails to external recipients or large distribution lists, which helps prevent data leakage, unintentional over-sharing, and excessive email traffic. MailTips serve as a lightweight but effective safeguard by nudging users to review recipients and message context before sending, reducing the risk of human error. In regulated or security-conscious environments, this feature reinforces compliance by helping users adhere to organizational communication policies in real time.",
"LevelOfRisk": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -494,7 +522,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "Microsoft Teams channel email addresses are an optional feature that enables users to send emails directly into a Teams channel. When enabled, each channel is assigned a unique email address that users can use to forward messages, share content, or initiate discussions from outside Teams. While this can enhance collaboration by bridging email and Teams-based communication, the generated email addresses are typically not part of the organization’s primary domain, and their usage is subject to broader Microsoft 365 infrastructure settings.",
"AdditionalInformation": "Channel email addresses introduce potential security and governance concerns, as they are not managed under the organization’s domain and are exposed to external communication. If an attacker is able to discover or guess a channel’s email address, they could send messages directly into Teams, potentially introducing phishing links, malicious attachments, or inappropriate content into collaborative spaces. Furthermore, since organizations have limited control over the security configurations and exposure of these addresses, they may become a blind spot in security monitoring and email filtering. Disabling or restricting the use of Teams channel email addresses helps reduce the attack surface, prevent unauthorized message injection, and strengthen the overall security posture of Microsoft Teams.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -511,7 +540,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "This policy governs how external access is managed in Microsoft Teams, specifically determining whether users in your organization can communicate and collaborate with individuals from external domains. Administrators can configure this setting to: • Allow communication with all external domains • Block all external domains • Allow only specific (approved) external domains using an allowlist When external access is enabled, users can chat, invite external participants to meetings, and use audio/video conferencing with users in other Microsoft 365 or federated organizations. Recommended Configuration: To reduce exposure, it is recommended to either allow only specific external domains with whom collaboration is necessary or block all external domains entirely.",
"AdditionalInformation": "While external collaboration can be valuable, unrestricted access to external domains introduces significant security risks. Without proper controls, users may inadvertently engage with untrusted or malicious entities, opening the door to phishing, social engineering, malware delivery, or data exfiltration. Notable threats that have leveraged Teams’ external access features include: • DarkGate malware distributed through malicious Teams messages • Phishing and impersonation campaigns by actors like Midnight Blizzard (APT29) • GIFShell, a technique for covert communication using GIFs within Teams • Username enumeration, allowing attackers to confirm the existence of user accounts By allowlisting only trusted domains, organizations retain the benefits of external collaboration while maintaining tight control over who can interact with internal users. This aligns with zero trust principles and helps ensure that external communication is both intentional and secure.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -528,7 +558,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "This policy setting in Microsoft Teams controls whether users in your organization can chat or join meetings with external Teams users who are not affiliated with a managed organization—for example, users of Microsoft Teams (free) or those without an associated Microsoft Entra ID (formerly Azure AD) tenant. These unmanaged accounts operate outside of enterprise governance and lack the administrative oversight, compliance enforcement, and security controls typically applied in organizational environments. Recommended Configuration: Set the policy to “Off” for “People in my organization can communicate with Teams users whose accounts aren’t managed by an organization” to block communication with unmanaged Teams users.",
"AdditionalInformation": "Allowing communication with unmanaged external Teams users introduces a significant security risk. Since anyone can register for a free Teams account, attackers can easily create unmanaged identities and attempt to initiate contact with internal users. These interactions can be used to deliver malicious content, perform social engineering, or carry out reconnaissance. Documented attacks exploiting this communication channel include: • DarkGate malware delivery via malicious messages • Phishing and impersonation campaigns attributed to Midnight Blizzard (APT29) • GIFShell, a technique allowing covert exfiltration via GIFs in Teams chats • Username enumeration, enabling attackers to identify valid users in an organization Disabling communication with unmanaged Teams users helps enforce a zero trust posture, ensuring that all external interactions occur only with verified and trusted organizations under enforceable security policies. This reduces the organization’s exposure to external threats, protects sensitive communications, and upholds compliance standards.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -545,7 +576,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "This policy setting in Microsoft Teams controls whether external users with unmanaged Teams accounts—such as those using Microsoft Teams (free)—can initiate conversations with users in your organization. These unmanaged users do not belong to a verified Microsoft Entra (Azure AD) tenant and are not subject to organizational controls or governance. Recommended Configuration: Uncheck the option “External users with Teams accounts not managed by an organization can contact users in my organization” to prevent these users from initiating communication. This setting is designed as an additional safeguard to complement the broader policy that disables communication with unmanaged Teams users entirely. In scenarios where an organization allows limited interaction with such users, this control ensures that only internal users can initiate communication, further reducing exposure to unsolicited or malicious contact attempts.",
"AdditionalInformation": "Enabling unmanaged Teams users to initiate contact with internal users poses a significant security risk, as anyone can easily register for a free Teams account with minimal identity verification. Threat actors can exploit this feature to deliver malicious content, impersonate legitimate contacts, or conduct reconnaissance by probing user availability and behavior. Notable real-world threats facilitated through external Teams access include:• DarkGate malware delivered via malicious chats • Social engineering and phishing campaigns by advanced threat actors such as Midnight Blizzard (APT29) • GIFShell, a covert data exfiltration method using GIFs in Teams • Username enumeration, enabling discovery of valid user accounts within an organization By preventing unmanaged external users from initiating conversations, organizations can better protect their internal users from unsolicited and potentially harmful contact attempts. This policy reinforces a defense-in-depth strategy, ensuring that even in exceptional cases where limited unmanaged communication is permitted, external contact remains tightly controlled and monitored.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -562,7 +594,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "This policy setting in Microsoft Teams controls who can read and write messages in the meeting chat. It allows administrators or meeting organizers to specify whether chat is available to everyone, only specific roles (such as presenters), or is disabled entirely for participants. This setting applies to chat interactions during the meeting and helps manage the flow and visibility of information shared in the chat pane.",
"AdditionalInformation": "Limiting chat access to only authorized participants helps prevent the unintended disclosure of sensitive information and reduces the risk of inappropriate or disruptive content being shared during a meeting. In meetings involving confidential topics or external participants, restricting chat can safeguard against data leakage and maintain focus on the meeting agenda.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -579,7 +612,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "This policy setting in Microsoft Teams determines who is allowed to present content during a meeting. Presenters have elevated permissions that allow them to share their screen, display files, manage participants, and control other collaborative features. This setting can be configured at the organizational or meeting level to allow only organizers, co-organizers, or a designated group of participants to present.",
"AdditionalInformation": "Restricting presentation privileges to authorized individuals helps ensure that only trusted participants can share content with the group. This minimizes the risk of inappropriate, disruptive, or unapproved material being displayed, whether intentionally or accidentally.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -596,7 +630,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "This policy setting in Microsoft Teams provides control over who can present content and who can request control of shared content during a meeting. It enables administrators and meeting organizers to limit these privileges to internal, trusted participants, while restricting or blocking external participants—including guests, external users, and anonymous users—from taking control of the presentation or initiating content sharing.",
"AdditionalInformation": "Restricting presentation and control capabilities to authorized, internal participants significantly reduces the risk of accidental or malicious content sharing, interruptions, or abuse of meeting privileges. External participants—including guests, federated users, and anonymous joiners—may not be subject to the same identity verification or policy enforcement as users within the organization.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -613,7 +648,8 @@
"SubSection": "1.2 Authorization",
"AttributeDescription": "This policy setting in Microsoft Teams determines whether a user is allowed to initiate the recording of a meeting in progress. When enabled, participants with the appropriate permissions can start recording audio, video, and screen-sharing content during the session.",
"AdditionalInformation": "Restricting the ability to start a meeting recording ensures that only authorized individuals—such as organizers, co-organizers, team leads, or designated presenters—can capture meeting content. This is especially important for meetings that involve sensitive, confidential, or regulated information, where inappropriate or unauthorized recording could lead to data exposure, compliance violations, or reputational harm.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -630,7 +666,8 @@
"SubSection": "1.3 Privilege Escalation Prevention",
"AttributeDescription": "Each tenant should have more than one designated Global Administrator to ensure both accountability and redundancy in case one administrator leaves the organization. However, it’s equally important to limit the total number of Global Administrators to no more than four to reduce the overall security risk. Ideally, Global Administrator accounts should not have any user licenses assigned, limiting their exposure to commonly targeted services.",
"AdditionalInformation": "Relying on a single Global Administrator creates a risk of unmonitored malicious activity. On the other hand, having too many Global Administrators increases the likelihood that one of their accounts could be compromised. A balanced approach supports both oversight and security.",
"LevelOfRisk": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -647,7 +684,8 @@
"SubSection": "1.3 Privilege Escalation Prevention",
"AttributeDescription": "Administrative accounts are privileged identities with elevated access to critical data, user management, and system settings. Assigning a license to these accounts may grant access to various applications, depending on the license type. The recommended practice is to avoid assigning licenses to privileged accounts altogether. If licensing is required—for example, to enable features such as Identity Protection, Privileged Identity Management (PIM), or Conditional Access—only Microsoft Entra ID P1 or P2 licenses should be used, as they do not include access to potentially vulnerable services like email or Teams.",
"AdditionalInformation": "Minimizing application access for administrative accounts significantly reduces the attack surface associated with high-privilege identities. Access to tools like mailboxes or collaboration apps increases the risk of exposure to phishing or social engineering attacks. Administrative tasks should be performed using dedicated, unlicensed accounts, while day-to-day activities should be conducted through separate, unprivileged “daily driver” accounts.",
"LevelOfRisk": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -664,7 +702,8 @@
"SubSection": "1.3 Privilege Escalation Prevention",
"AttributeDescription": "App registration allows users to register custom or third-party applications for use within the organization’s Microsoft Entra ID directory. These applications can request access to organizational data and integrate with various Microsoft 365 services.",
"AdditionalInformation": "While there are valid business cases for registering applications, this capability should be restricted to prevent unauthorized or insecure integrations. Attackers can exploit this feature by using compromised accounts to grant persistent access to third-party applications, enabling data exfiltration without needing to maintain direct control of the breached account. App registration should be disabled for standard users unless there is a clear business need and strong security controls—such as app consent policies and review workflows—are in place.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -681,7 +720,8 @@
"SubSection": "1.3 Privilege Escalation Prevention",
"AttributeDescription": "By default, non-privileged users can create new Microsoft Entra tenants through the “Manage tenant” option in the Entra admin portal. When a user creates a tenant, the action is logged in the Audit Log under the category DirectoryManagement with the activity Create Company. The user who creates the tenant is automatically assigned the Global Administrator role for that tenant. Note that newly created tenants do not inherit any of the organization’s existing security or configuration settings.",
"AdditionalInformation": "Allowing unrestricted tenant creation introduces the risk of unauthorized or unmanaged environments, often referred to as shadow IT. These tenants may be mistakenly perceived as part of the organization’s secure infrastructure, leading users to adopt them for business use. This can fragment IT governance, complicate security oversight, and increase the likelihood of data exposure or policy violations. Restricting tenant creation ensures centralized control over the organization’s cloud environment and helps maintain consistent security and compliance standards.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -698,7 +738,8 @@
"SubSection": "1.3 Privilege Escalation Prevention",
"AttributeDescription": "Organizations can control whether end users and group owners are allowed to grant consent to applications, or whether such requests require administrator review and approval. While allowing user consent can enhance productivity by enabling access to useful apps, it also introduces potential security risks if not properly managed.",
"AdditionalInformation": "Attackers often exploit application consent mechanisms by tricking users into authorizing malicious apps, thereby gaining access to sensitive company data. Disabling user consent for future app authorizations helps mitigate this risk by reducing the overall attack surface. When user consent is disabled, any existing consent remains valid, but all future consent requests must be explicitly approved by an administrator—ensuring better oversight and stronger security controls.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -715,7 +756,8 @@
"SubSection": "1.3 Privilege Escalation Prevention",
"AttributeDescription": "Microsoft Entra ID, as part of the Microsoft Entra suite, allows organizations to control what external guest users can view and access within the directory. By default, guest users are assigned a more limited permission level than internal members, who receive the full set of user permissions. These directory-level permissions apply across Microsoft Entra services, including Microsoft Graph, PowerShell v2, the Azure portal, and the My Apps portal. They also affect Microsoft 365 services that rely on Microsoft 365 Groups for collaboration—such as Outlook, Microsoft Teams, and SharePoint—though they do not override guest-specific settings within Teams or SharePoint. The recommended configuration is to ensure that guest users have limited access to directory properties and group memberships, or an even more restrictive setting.",
"AdditionalInformation": "Restricting guest access helps prevent unauthorized enumeration of users and groups within the directory—a common reconnaissance tactic used by attackers during the early stages of a targeted attack (as defined in the Cyber Kill Chain framework). Limiting this visibility reduces the organization’s exposure to potential threats and supports a stronger security posture.",
"LevelOfRisk": 3
"LevelOfRisk": 3,
"Weight": 10
}
]
},
@@ -732,7 +774,8 @@
"SubSection": "1.3 Privilege Escalation Prevention",
"AttributeDescription": "By default, all users in the organization—including B2B collaboration guest users—can invite external users to collaborate via Microsoft Entra ID. This invitation capability can be broadly enabled or disabled, or it can be restricted to users in specific administrative roles. The recommended configuration is to limit guest invitations to only those users assigned to specific admin roles.",
"AdditionalInformation": "Restricting who can invite external guests reduces the risk of unauthorized or unmanaged external access. By limiting this ability to trusted administrative roles, organizations can maintain tighter control over their environment and reduce potential exposure to security threats originating from unvetted accounts.",
"LevelOfRisk": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -749,7 +792,8 @@
"SubSection": "1.3 Privilege Escalation Prevention",
"AttributeDescription": "In complex environments, organizations may need to place limits on authentication session durations to reduce risk. Microsoft Entra Conditional Access (CA) policies allow organizations to enforce session controls based on user roles, device state, location, and application sensitivity. Common scenarios include: • Access from unmanaged or shared devices • External access to sensitive resources • High-privileged user accounts • Business-critical applications The following configurations are recommended: • Sign-in frequency: Require reauthentication at least every 4 hours for Microsoft 365 E3 tenants, or every 24 hours for E5 tenants using Privileged Identity Management (PIM). • Persistent browser session: Set to Never persistent. Note: These settings can be integrated into the Conditional Access policy that enforces multifactor authentication for users in administrative roles.",
"AdditionalInformation": "Limiting the duration of authentication sessions helps prevent long-lived sessions that could be hijacked by attackers. Requiring periodic reauthentication ensures that a session cannot remain active indefinitely. Disabling persistent browser sessions further reduces the risk of drive-by browser attacks and ensures that session cookies are not stored, leaving nothing behind for an attacker to reuse in case of a compromised device.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -766,7 +810,8 @@
"SubSection": "1.3 Privilege Escalation Prevention",
"AttributeDescription": "Microsoft OneDrive allows users to sign in with their organizational (cloud tenant) account and sync their OneDrive files—including selected folders or the entire contents of their storage—to a local computer. By default, synchronization is permitted on any device where OneDrive is installed, regardless of whether the device is Microsoft Entra ID Joined, Hybrid Entra ID Joined, or Active Directory Domain Joined. To improve control over where organizational data can be synchronized, it is recommended to restrict OneDrive syncing to only those devices joined to specific, trusted domains by enabling the policy: “Allow syncing only on computers joined to specific domains”, and specifying the appropriate Active Directory (AD) domain GUID(s)",
"AdditionalInformation": "Allowing users to sync OneDrive data to unmanaged or personal devices introduces significant risk, as those endpoints may not comply with corporate security policies, lack endpoint protection, or be subject to malicious activity. When organizational data is synchronized to such devices, the organization loses visibility and control over how that data is accessed, shared, or protected. This opens the door to accidental data leaks, intentional misuse, or loss of sensitive information through theft or compromise. Restricting synchronization to verified, domain-joined devices ensures that only endpoints under the organization’s management and monitoring can access and store OneDrive data locally. This approach aligns with zero-trust principles, enforces data governance policies, and significantly reduces the risk of unauthorized access or exfiltration.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -783,7 +828,8 @@
"SubSection": "2.1 Network",
"AttributeDescription": "In Microsoft 365 environments—whether using Exchange Online mailboxes or standalone Exchange Online Protection (EOP)—connection filtering policies play a critical role in determining the trustworthiness of incoming email based on the source IP address. The default connection filter policy includes three main components: the IP Allow List, the IP Block List, and a Safe List. These lists influence how email messages are processed before any content filtering occurs. It is recommended that the IP Allow List remains empty or undefined to avoid bypassing essential security checks.",
"AdditionalInformation": "Email originating from IP addresses on the Allow List bypasses several key layers of protection, including spam filtering and sender authentication protocols such as SPF, DKIM, and DMARC. Without additional safeguards like mail flow rules, this configuration introduces a significant risk: malicious actors can exploit the Allow List to deliver spoofed or harmful emails directly to users’ inboxes. Maintaining an empty IP Allow List ensures that all messages undergo full evaluation and filtering, reducing the likelihood of malware, phishing attempts, and impersonation attacks reaching end users.",
"LevelOfRisk": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -800,7 +846,8 @@
"SubSection": "2.1 Network",
"AttributeDescription": "In Microsoft 365 environments—whether using Exchange Online mailboxes or standalone Exchange Online Protection (EOP)—connection filtering policies are used to evaluate and classify incoming email based on the IP address of the sending server. The default connection filter policy includes three main components: the IP Allow List, the IP Block List, and the Safe List. The Safe List is a Microsoft-managed, dynamically updated set of sender IP addresses that are automatically treated as trusted sources. The recommended configuration is to have the Safe List disabled (set to Off or False) to ensure all incoming mail is properly evaluated by the organization’s email security policies.",
"AdditionalInformation": "When the Safe List is enabled, messages from IP addresses on this list bypass key security mechanisms, including spam filtering and sender authentication checks such as SPF, DKIM, and DMARC. Although Microsoft manages this list dynamically, administrators have no visibility or control over which senders are included. As a result, allowing Safe List traffic to skip verification introduces significant risk—malicious actors could exploit this blind spot to deliver spam, phishing, or malware directly to user inboxes. Disabling the Safe List ensures that all messages undergo full inspection, allowing organizations to maintain strict control over the email filtering pipeline and reduce the likelihood of successful compromise.",
"LevelOfRisk": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -817,7 +864,8 @@
"SubSection": "2.1 Network",
"AttributeDescription": "The SMTP AUTH (Simple Mail Transfer Protocol Authentication) setting in Exchange Online controls whether authenticated client SMTP submission is enabled at the organization level. This legacy protocol is used primarily by older applications and devices to send email via SMTP using basic authentication. By default, Microsoft recommends disabling SMTP AUTH at the tenant level to enhance security posture. Modern email clients and applications that connect to Microsoft 365 mailboxes no longer require SMTP AUTH and can use more secure, modern authentication methods (such as OAuth 2.0).",
"AdditionalInformation": "SMTP AUTH is an outdated and insecure protocol that relies on basic authentication, which transmits credentials in plaintext and lacks support for multifactor authentication. Leaving this protocol enabled increases the risk of credential theft, account compromise, and unauthorized access, especially in environments not protected by additional controls such as Conditional Access or legacy protocol blocking. Disabling SMTP AUTH supports the principle of least functionality by reducing protocol exposure and hardening the email infrastructure against exploitation attempts. This action also aligns with Microsoft’s broader security guidance and helps organizations phase out legacy authentication methods in favor of modern, secure protocols.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -834,7 +882,8 @@
"SubSection": "2.2 Storage",
"AttributeDescription": "The AdditionalStorageProvidersAvailable setting in Microsoft 365 controls whether users can connect to and open files from third-party storage services while using Outlook on the Web (OWA). When enabled, users may link external services such as Dropbox, Box, Google Drive, Facebook, or OneDrive Personal to access and interact with files directly within the Outlook web interface. Although this can enhance user productivity, it also introduces third-party services that Microsoft does not govern, meaning their terms of use, privacy policies, and security practices are outside the organization’s control. To mitigate potential risks, it is recommended to restrict or disable access to additional storage providers, limiting file access to only trusted organizational sources.",
"AdditionalInformation": "Allowing connections to external storage providers from within Outlook on the Web significantly increases the risk of data leakage and malware exposure. Users may inadvertently upload or download sensitive organizational data to or from non-sanctioned storage platforms, where proper security controls and compliance measures may not be in place. Additionally, files retrieved from these services could serve as vectors for malware or phishing payloads, especially if users are unaware of their origin or if access controls on those platforms are weak. Restricting access to third-party storage providers helps enforce data governance policies, reduces the organization’s attack surface, and ensures that sensitive communications and files remain within controlled and monitored environments. This is especially important in industries with regulatory or compliance obligations.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -851,7 +900,8 @@
"SubSection": "2.2 Storage",
"AttributeDescription": "Microsoft Teams facilitates collaboration by enabling users to share and access files within chat, meetings, and channels. By default, file sharing in Teams is integrated with SharePoint Online for team channels and OneDrive for Business for private chats. However, the platform also supports third-party cloud storage providers such as Dropbox, Box, and Google Drive, which can be made available within the Teams interface. Administrators have the ability to configure and restrict which external storage providers are accessible to end users. This helps align file-sharing capabilities with organizational data governance and compliance requirements. Note: While Skype for Business was officially deprecated on July 31, 2021, some configuration settings inherited from its infrastructure may still apply for a limited time. Refer to Microsoft’s official documentation for ongoing support timelines.",
"AdditionalInformation": "Allowing unrestricted access to third-party cloud storage providers within Microsoft Teams can undermine an organization’s data protection and compliance efforts. Users may unintentionally store or share sensitive information using non-sanctioned platforms that fall outside of the organization’s control, monitoring, or security policies. By restricting file-sharing capabilities to only approved storage providers, organizations can ensure that collaboration remains within trusted ecosystems. This reduces the risk of data leakage, non-compliant data transfers, and unauthorized access, while also reinforcing secure and consistent file management practices across the collaboration environment.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -868,7 +918,8 @@
"SubSection": "2.3 Application",
"AttributeDescription": "The Common Attachment Types Filter allows users to block both well-known and custom-defined malicious file types from being attached to email messages.",
"AdditionalInformation": "By blocking commonly exploited file types, this filter helps prevent the delivery of malware-laden attachments, reducing the risk of endpoint compromise and broader system infection.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -885,7 +936,8 @@
"SubSection": "2.3 Application",
"AttributeDescription": "The Common Attachment Types Filter allows users to block both known and custom-defined malicious file types from being attached to email messages. While Microsoft provides a default policy that blocks 53 high-risk file extensions, organizations can extend this protection by defining their own custom list. This recommendation includes a broader set of 186 potentially dangerous file extensions, offering a more robust safeguard. Although comprehensive, the list is not exhaustive and should be tailored to fit organizational needs.",
"AdditionalInformation": "Blocking file types commonly associated with malware helps prevent the delivery of malicious payloads that can compromise hosts, exfiltrate data, or facilitate phishing attacks. By enforcing a strict attachment policy, organizations reduce their exposure to threats delivered through legacy formats, binary executables, and compressed archives. Allow-listing only those file types necessary for business operations and blocking all others is an effective strategy for mitigating risks such as Business Email Compromise (BEC) and enhancing overall email security posture.",
"LevelOfRisk": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -902,7 +954,8 @@
"SubSection": "2.3 Application",
"AttributeDescription": "In Exchange Online, administrators have the ability to control who can install and manage Outlook add-ins within the Microsoft 365 environment. By default, end users are allowed to install third-party or custom add-ins directly in their Outlook desktop client, which can access data within the application such as emails, calendar events, and contacts. To enhance security and reduce potential risks, it is recommended to restrict add-in management privileges to a limited set of trusted administrators and users. This can be configured via the Microsoft 365 admin center or PowerShell, providing centralized control over which add-ins are allowed and who can deploy them.",
"AdditionalInformation": "Allowing end users to install Outlook add-ins introduces a potential attack surface, especially if the add-ins are vulnerable, poorly maintained, or intentionally malicious. Threat actors can exploit this capability to gain unauthorized access to sensitive mailbox data or to execute malicious code within the Outlook client. By disabling or restricting user-installed add-ins, organizations can significantly reduce the risk of data exfiltration, phishing, and privilege abuse. Managing add-ins centrally ensures that only vetted and trusted integrations are used, aligning with best practices for securing email clients and minimizing exposure to third-party threats.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -919,7 +972,8 @@
"SubSection": "2.3 Application",
"AttributeDescription": "This meeting policy setting in Microsoft Teams governs whether users in your organization can read or write messages in meeting chats hosted by external, untrusted organizations. If the external meeting is hosted by an organization that has been explicitly designated as trusted, this restriction does not apply.",
"AdditionalInformation": "Allowing unrestricted chat participation in meetings hosted by untrusted external organizations increases the risk of exposure to malicious content, including links, files, or payloads designed to exploit user behavior or application vulnerabilities.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -937,7 +991,8 @@
"SubSection": "2.3 Application",
"AttributeDescription": "User reporting settings in Microsoft Teams and Microsoft 365 allow end users to report messages they believe to be malicious or suspicious, enabling quicker response and investigation by security teams. To ensure the reporting feature functions as intended, this recommendation encompasses three distinct but interdependent settings that must all be correctly configured: 1. Teams Admin Center – User Reporting: This setting controls whether users can report messages directly from the Teams interface. It is enabled by default for new tenants. If disabled, users cannot report messages in Teams, and downstream settings in Microsoft Defender will not have any effect. 2. Microsoft 365 Defender Portal – User Reporting Integration: Also enabled by default in new tenants, this setting must be explicitly enabled for existing tenants. It ensures that messages reported from Teams are properly surfaced on the “User reported” tab of the Submissions page in Microsoft 365 Defender. 3. Defender – Report Message Destinations: This broader configuration applies to multiple Microsoft 365 services, including Teams. It allows organizations to control where reported messages are routed, such as keeping them within the organization or forwarding them to Microsoft for deeper analysis. Given its influence on how user submissions are processed, it is included as a required configuration in this assessment.",
"AdditionalInformation": "Enabling user reporting equips employees with a straightforward mechanism to flag suspicious or potentially malicious content in Teams, acting as a critical early warning system for security teams. This improves organizational responsiveness to phishing, social engineering, or targeted attacks that may initially evade automated detection.",
"LevelOfRisk": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
},
@@ -954,7 +1009,8 @@
"SubSection": "3.1 Logging",
"AttributeDescription": "The setting “Mailbox auditing on by default” determines whether mailbox auditing is automatically enabled across all mailboxes in the organization, regardless of their individual auditing configuration. When this setting is configured as False, it enables auditing at the organization level, overriding the AuditEnabled property for individual mailboxes—even if it is explicitly set to False. With this setting enabled, default audit actions are automatically recorded for all mailboxes without requiring manual configuration. Conversely, disabling this setting (True) effectively turns off mailbox auditing across the organization and overrides any mailbox-level auditing settings. The consequences of disabling this setting include: • Mailbox auditing is completely disabled organization-wide. • No mailbox actions are logged, even if AuditEnabled is set to True for individual mailboxes. • New mailboxes do not inherit auditing, and setting AuditEnabled=True has no effect. • Bypass audit rules set via Set-MailboxAuditBypassAssociation are ignored. • Existing audit records remain in place until they expire based on the audit log retention policy. The recommended configuration is to set this value to False at the organization level to ensure auditing is enforced consistently.",
"AdditionalInformation": "Enforcing mailbox auditing by default ensures that audit logging cannot be unintentionally or maliciously disabled on individual mailboxes. This setting provides vital visibility for forensic investigations and incident response (IR) teams, allowing them to trace suspicious or malicious activity—such as unauthorized inbox access, message deletion, or rule manipulation—that may signal account compromise. Consistent auditing across all mailboxes is critical for detecting threat actor behaviors (TTPs) and correlating events across users. While organizations without Microsoft 365 E5 licenses are limited to 90 days of audit log retention, enabling this setting still significantly improves detection and accountability within that window.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -971,7 +1027,8 @@
"SubSection": "3.1 Logging",
"AttributeDescription": "As of January 2019, Microsoft enables mailbox audit logging by default across all organizations. This feature ensures that specific actions performed by mailbox owners, delegates, and administrators are automatically captured and recorded. These audit records can then be searched by administrators through the mailbox audit log in Microsoft 365. Each mailbox type—whether user, shared, resource, or public folder—can have tailored audit settings to track activities that are most relevant to the organization. While audit logging is enabled by default at the organizational level, it is important to explicitly configure the AuditEnabled property to True on all user mailboxes, and to expand the list of audited actions beyond the Microsoft defaults to meet specific visibility or compliance needs. Note: This recommendation is particularly relevant to users with Microsoft 365 E3 licenses, where audit actions differ slightly from the default configurations in E5.",
"AdditionalInformation": "Mailbox auditing plays a critical role in supporting both regulatory compliance and security monitoring. Whether investigating unauthorized configuration changes, potential account compromise, or insider threats, detailed mailbox audit logs provide essential evidence for security operations, forensic analysis, and general administrative oversight. While mailbox auditing is enabled by default for most user mailboxes, certain mailbox types—such as Resource Mailboxes, Public Folder Mailboxes, and the DiscoverySearch Mailbox—do not inherit the organizational auditing default. For these mailboxes, AuditEnabled must be manually set to True to ensure relevant activities are captured. Note: Organizations without Microsoft 365 E5 licenses are subject to a 90-day audit log retention limit, but enabling comprehensive mailbox auditing remains a best practice for operational readiness and incident response.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -988,7 +1045,8 @@
"SubSection": "3.1 Logging",
"AttributeDescription": "Since January 2019, mailbox audit logging has been enabled by default in all Microsoft 365 organizations. This feature ensures that specific actions performed by mailbox owners, delegates, and administrators are automatically captured and stored as audit records. These logs are accessible to administrators through the Microsoft 365 mailbox audit log, enabling visibility into key mailbox-level activity. Although logging is enabled by default, each mailbox—particularly user and shared mailboxes—can have custom audit actions assigned to capture the specific types of events deemed valuable by the organization. For environments with Microsoft 365 E5 licenses or the advanced auditing add-on, it is recommended to explicitly set AuditEnabled to True on all user mailboxes and to configure additional audit actions beyond Microsoft’s default settings for enhanced visibility. Note: This recommendation specifically applies to E5 or equivalent auditing-enabled license holders, as the available audit depth and event coverage differ from E3.",
"AdditionalInformation": "Mailbox audit logging is essential for supporting security investigations, regulatory compliance, and operational forensics in Microsoft 365. Whether you’re tracking unauthorized changes, detecting suspicious access, or conducting post-incident analysis, having a complete and accurate mailbox audit trail is critical. While audit logging is broadly applied by default, certain mailbox types bypass the organizational setting and require manual configuration to enable auditing. These include: • Resource Mailboxes • Public Folder Mailboxes • DiscoverySearch Mailboxes For these mailbox types, the AuditEnabled property must be explicitly set to True to ensure that audit events are captured. Important: Without advanced auditing (included in E5 or via add-on), mailbox audit logs are retained for only 90 days, limiting the historical window for investigations. Nonetheless, enabling detailed auditing remains a key best practice for maintaining strong visibility and compliance readiness.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1005,7 +1063,8 @@
"SubSection": "3.1 Logging",
"AttributeDescription": "The AuditBypassEnabled setting in Microsoft 365 allows specific user or computer accounts to bypass mailbox audit logging, meaning that any actions they perform on mailboxes will not be recorded in the audit logs. This includes actions such as reading, deleting, moving, or modifying messages.",
"AdditionalInformation": "Allowing an account to bypass mailbox audit logging creates a blind spot in security monitoring. If the account is compromised, misused, or maliciously configured, it can access and interact with mailboxes without leaving any trace in the logs. This significantly undermines the organization’s ability to conduct forensic investigations, detect insider threats, or comply with audit requirements.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1022,7 +1081,8 @@
"SubSection": "3.2 Retention",
"AttributeDescription": "Audit log search in the Microsoft Purview compliance portal allows organizations to track and retain user and administrator activities across Microsoft 365 services. When enabled, audit events—such as sign-ins, file access, configuration changes, and other operational actions—are captured and stored for up to 90 days by default. While some organizations may choose to integrate auditing data with third-party Security Information and Event Management (SIEM) systems, audit log search in Microsoft Purview remains a critical native capability for centralized visibility and incident response. Although global administrators have the ability to disable audit log search, it is generally recommended to keep it enabled to maintain full visibility into user and system activity.",
"AdditionalInformation": "Activating audit log search provides essential forensic and compliance value. It enables organizations to detect anomalous behavior, investigate potential security incidents, and demonstrate adherence to regulatory and legal requirements. In addition, it supports operational monitoring, internal audits, and proactive threat detection. By retaining and centralizing audit data within the Microsoft 365 ecosystem, security and compliance teams gain faster access to actionable insights, reducing response times and strengthening the organization’s overall security posture.",
"LevelOfRisk": 5
"LevelOfRisk": 5,
"Weight": 1000
}
]
},
@@ -1039,7 +1099,8 @@
"SubSection": "3.3 Monitoring",
"AttributeDescription": "Exchange Online Protection (EOP) is Microsoft’s cloud-based email filtering service designed to safeguard organizations against spam, malware, and other email-borne threats. It is included by default in all Microsoft 365 tenants with Exchange Online mailboxes. EOP provides customizable anti-malware policies that allow administrators to define protection settings and configure alerts for detected malicious activity.",
"AdditionalInformation": "Enabling notifications for malware detections ensures that administrators are alerted when an internal user sends a message containing malware. Such incidents may signal a compromised user account or infected device, requiring immediate investigation to mitigate potential security breaches.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1056,7 +1117,8 @@
"SubSection": "4.1 In-Transit",
"AttributeDescription": "DomainKeys Identified Mail (DKIM) is one of the three key email authentication technologies—alongside SPF and DMARC—used to protect domains from being spoofed by malicious actors. DKIM allows organizations to apply a cryptographic digital signature to the header of outbound email messages. When properly configured, DKIM enables a domain to associate its identity with the message, allowing recipient email systems to verify the authenticity of the sender. Combined with SPF and DMARC, DKIM helps prevent unauthorized use of your domain in phishing or spoofing attacks.",
"AdditionalInformation": "Enabling DKIM in Office 365 ensures that all outbound emails sent via Exchange Online are cryptographically signed. This enables recipient mail servers to verify that messages originate from an authorized source, significantly reducing the risk of email spoofing and reinforcing trust in the organization’s email communications.",
"LevelOfRisk": 4
"LevelOfRisk": 4,
"Weight": 100
}
]
},
@@ -1073,7 +1135,8 @@
"SubSection": "4.1 In-Transit",
"AttributeDescription": "Password Hash Synchronization (PHS) is a hybrid identity sign-in method that enables secure synchronization of user credentials from an on-premises Active Directory to Microsoft Entra ID. Microsoft Entra Connect performs this by syncing a hash of the password hash, ensuring credentials are not exposed in transit or storage. Note: This recommendation applies only to Microsoft 365 tenants configured with Entra Connect synchronization in a hybrid environment. It does not apply to tenants using federated domain configurations.",
"AdditionalInformation": "PHS simplifies the user experience by allowing a single password to be used across both on-premises and cloud resources. It also enables leaked credential detection via Microsoft Entra ID Protection, helping identify compromised accounts when passwords appear in known data breaches or public forums. Compared to other synchronization methods like federation, PHS offers greater resilience—users can still sign in to Microsoft 365 even if connectivity to the on-premises environment is temporarily unavailable.",
"LevelOfRisk": 2
"LevelOfRisk": 2,
"Weight": 8
}
]
}

1
prowler/lib/check/compliance_models.py
View File

@@ -193,6 +193,7 @@ class Prowler_ThreatScore_Requirement_Attribute(BaseModel):
AttributeDescription: str
AdditionalInformation: str
LevelOfRisk: int
Weight: int
# Base Compliance Model

4
prowler/lib/outputs/compliance/prowler_threatscore/models.py
View File

@@ -21,6 +21,7 @@ class ProwlerThreatScoreAWSModel(BaseModel):
Requirements_Attributes_AttributeDescription: str
Requirements_Attributes_AdditionalInformation: str
Requirements_Attributes_LevelOfRisk: int
Requirements_Attributes_Weight: int
Status: str
StatusExtended: str
ResourceId: str
@@ -47,6 +48,7 @@ class ProwlerThreatScoreAzureModel(BaseModel):
Requirements_Attributes_AttributeDescription: str
Requirements_Attributes_AdditionalInformation: str
Requirements_Attributes_LevelOfRisk: int
Requirements_Attributes_Weight: int
Status: str
StatusExtended: str
ResourceId: str
@@ -73,6 +75,7 @@ class ProwlerThreatScoreGCPModel(BaseModel):
Requirements_Attributes_AttributeDescription: str
Requirements_Attributes_AdditionalInformation: str
Requirements_Attributes_LevelOfRisk: int
Requirements_Attributes_Weight: int
Status: str
StatusExtended: str
ResourceId: str
@@ -99,6 +102,7 @@ class ProwlerThreatScoreM365Model(BaseModel):
Requirements_Attributes_AttributeDescription: str
Requirements_Attributes_AdditionalInformation: str
Requirements_Attributes_LevelOfRisk: int
Requirements_Attributes_Weight: int
Status: str
StatusExtended: str
ResourceId: str

40
prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore.py
View File

@@ -24,7 +24,8 @@ def get_prowler_threatscore_table(
muted_count = []
pillars = {}
score_per_pillar = {}
number_findings_per_pillar = {}
max_score_per_pillar = {}
counted_findings = []
for index, finding in enumerate(findings):
check = bulk_checks_metadata[finding.check_metadata.CheckID]
check_compliances = check.Compliance
@@ -34,12 +35,24 @@ def get_prowler_threatscore_table(
for attribute in requirement.Attributes:
pillar = attribute.Section
if pillar not in score_per_pillar.keys():
if not any(
[
pillar in score_per_pillar.keys(),
pillar in max_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
max_score_per_pillar[pillar] = 0
if index not in counted_findings:
if finding.status == "PASS":
score_per_pillar[pillar] += (
attribute.LevelOfRisk * attribute.Weight
)
max_score_per_pillar[pillar] += (
attribute.LevelOfRisk * attribute.Weight
)
counted_findings.append(index)
if pillar not in pillars:
pillars[pillar] = {"FAIL": 0, "PASS": 0, "Muted": 0}
@@ -60,14 +73,9 @@ def get_prowler_threatscore_table(
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}"
)
pillar_table["Score"].append(
f"{Style.BRIGHT}{Fore.RED}{(score_per_pillar[pillar] / max_score_per_pillar[pillar]) * 100:.2f}%{Style.RESET_ALL}"
)
if pillars[pillar]["FAIL"] > 0:
pillar_table["Status"].append(
f"{Fore.RED}FAIL({pillars[pillar]['FAIL']}){Style.RESET_ALL}"
@@ -110,10 +118,10 @@ def get_prowler_threatscore_table(
)
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}"
f"{Style.BRIGHT}\n=== Threat Score Guide ===\nThe lower the score, the higher the risk.{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}"
f"{Style.BRIGHT}(Only sections containing results appear, the score is calculated as the sum of the level of risk * weight of the passed findings divided by the sum of the risk * weight of all the findings){Style.RESET_ALL}"
)
print(f"\nDetailed results of {compliance_framework.upper()} are in:")
print(

2
prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_aws.py
View File

@@ -55,6 +55,7 @@ class ProwlerThreatScoreAWS(ComplianceOutput):
Requirements_Attributes_AttributeDescription=attribute.AttributeDescription,
Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation,
Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk,
Requirements_Attributes_Weight=attribute.Weight,
Status=finding.status,
StatusExtended=finding.status_extended,
ResourceId=finding.resource_uid,
@@ -81,6 +82,7 @@ class ProwlerThreatScoreAWS(ComplianceOutput):
Requirements_Attributes_AttributeDescription=attribute.AttributeDescription,
Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation,
Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk,
Requirements_Attributes_Weight=attribute.Weight,
Status="MANUAL",
StatusExtended="Manual check",
ResourceId="manual_check",

2
prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_azure.py
View File

@@ -55,6 +55,7 @@ class ProwlerThreatScoreAzure(ComplianceOutput):
Requirements_Attributes_AttributeDescription=attribute.AttributeDescription,
Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation,
Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk,
Requirements_Attributes_Weight=attribute.Weight,
Status=finding.status,
StatusExtended=finding.status_extended,
ResourceId=finding.resource_uid,
@@ -81,6 +82,7 @@ class ProwlerThreatScoreAzure(ComplianceOutput):
Requirements_Attributes_AttributeDescription=attribute.AttributeDescription,
Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation,
Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk,
Requirements_Attributes_Weight=attribute.Weight,
Status="MANUAL",
StatusExtended="Manual check",
ResourceId="manual_check",

2
prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_gcp.py
View File

@@ -55,6 +55,7 @@ class ProwlerThreatScoreGCP(ComplianceOutput):
Requirements_Attributes_AttributeDescription=attribute.AttributeDescription,
Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation,
Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk,
Requirements_Attributes_Weight=attribute.Weight,
Status=finding.status,
StatusExtended=finding.status_extended,
ResourceId=finding.resource_uid,
@@ -81,6 +82,7 @@ class ProwlerThreatScoreGCP(ComplianceOutput):
Requirements_Attributes_AttributeDescription=attribute.AttributeDescription,
Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation,
Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk,
Requirements_Attributes_Weight=attribute.Weight,
Status="MANUAL",
StatusExtended="Manual check",
ResourceId="manual_check",

2
prowler/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_m365.py
View File

@@ -55,6 +55,7 @@ class ProwlerThreatScoreM365(ComplianceOutput):
Requirements_Attributes_AttributeDescription=attribute.AttributeDescription,
Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation,
Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk,
Requirements_Attributes_Weight=attribute.Weight,
Status=finding.status,
StatusExtended=finding.status_extended,
ResourceId=finding.resource_uid,
@@ -81,6 +82,7 @@ class ProwlerThreatScoreM365(ComplianceOutput):
Requirements_Attributes_AttributeDescription=attribute.AttributeDescription,
Requirements_Attributes_AdditionalInformation=attribute.AdditionalInformation,
Requirements_Attributes_LevelOfRisk=attribute.LevelOfRisk,
Requirements_Attributes_Weight=attribute.Weight,
Status="MANUAL",
StatusExtended="Manual check",
ResourceId="manual_check",

0
prowler_threatscore_aws Normal file
View File

0
prowler_threatscore_azure Normal file
View File

0
prowler_threatscore_gcp Normal file
View File

0
prowler_threatscore_m365 Normal file
View File

50
tests/lib/outputs/compliance/fixtures.py
View File

@@ -875,6 +875,7 @@ PROWLER_THREATSCORE_AWS = Compliance(
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,
Weight=1000,
)
],
Checks=[
@@ -892,6 +893,7 @@ PROWLER_THREATSCORE_AWS = Compliance(
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,
Weight=10,
)
],
Checks=[],
@@ -917,6 +919,7 @@ PROWLER_THREATSCORE_AZURE = Compliance(
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,
Weight=1000,
)
],
Checks=[
@@ -934,6 +937,7 @@ PROWLER_THREATSCORE_AZURE = Compliance(
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,
Weight=10,
)
],
Checks=[],
@@ -959,6 +963,7 @@ PROWLER_THREATSCORE_GCP = Compliance(
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,
Weight=1000,
)
],
Checks=[
@@ -976,6 +981,51 @@ PROWLER_THREATSCORE_GCP = Compliance(
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,
Weight=10,
)
],
Checks=[],
),
],
)
PROWLER_THREATSCORE_M365_NAME = "prowler_threatscore_m365"
PROWLER_THREATSCORE_M365 = Compliance(
Framework="ProwlerThreatScore",
Version="1.0",
Provider="M365",
Description="Prowler ThreatScore Compliance Framework for M365 ensures that the M365 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,
Weight=1000,
)
],
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,
Weight=10,
)
],
Checks=[],

10
tests/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_aws_test.py
View File

@@ -66,6 +66,10 @@ class TestProwlerThreatScoreAWS:
output_data.Requirements_Attributes_LevelOfRisk
== PROWLER_THREATSCORE_AWS.Requirements[0].Attributes[0].LevelOfRisk
)
assert (
output_data.Requirements_Attributes_Weight
== PROWLER_THREATSCORE_AWS.Requirements[0].Attributes[0].Weight
)
assert output_data.Status == "PASS"
assert output_data.StatusExtended == ""
assert output_data.ResourceId == ""
@@ -113,6 +117,10 @@ class TestProwlerThreatScoreAWS:
output_data_manual.Requirements_Attributes_LevelOfRisk
== PROWLER_THREATSCORE_AWS.Requirements[1].Attributes[0].LevelOfRisk
)
assert (
output_data_manual.Requirements_Attributes_Weight
== PROWLER_THREATSCORE_AWS.Requirements[1].Attributes[0].Weight
)
assert output_data_manual.Status == "MANUAL"
assert output_data_manual.StatusExtended == "Manual check"
assert output_data_manual.ResourceId == "manual_check"
@@ -136,5 +144,5 @@ class TestProwlerThreatScoreAWS:
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"
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;REQUIREMENTS_ATTRIBUTES_WEIGHT;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;1000;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;10;MANUAL;Manual check;manual_check;Manual check;manual;False\r\n"
assert content == expected_csv

10
tests/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_azure_test.py
View File

@@ -77,6 +77,10 @@ class TestProwlerThreatScoreAzure:
output_data.Requirements_Attributes_LevelOfRisk
== PROWLER_THREATSCORE_AZURE.Requirements[0].Attributes[0].LevelOfRisk
)
assert (
output_data.Requirements_Attributes_Weight
== PROWLER_THREATSCORE_AZURE.Requirements[0].Attributes[0].Weight
)
assert output_data.Status == "PASS"
assert output_data.StatusExtended == ""
assert output_data.ResourceId == ""
@@ -124,6 +128,10 @@ class TestProwlerThreatScoreAzure:
output_data_manual.Requirements_Attributes_LevelOfRisk
== PROWLER_THREATSCORE_AZURE.Requirements[1].Attributes[0].LevelOfRisk
)
assert (
output_data_manual.Requirements_Attributes_Weight
== PROWLER_THREATSCORE_AZURE.Requirements[1].Attributes[0].Weight
)
assert output_data_manual.Status == "MANUAL"
assert output_data_manual.StatusExtended == "Manual check"
assert output_data_manual.ResourceId == "manual_check"
@@ -146,5 +154,5 @@ class TestProwlerThreatScoreAzure:
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"
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;REQUIREMENTS_ATTRIBUTES_WEIGHT;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;1000;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;10;MANUAL;Manual check;manual_check;Manual check;manual;False\r\n"
assert content == expected_csv

10
tests/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_gcp_test.py
View File

@@ -72,6 +72,10 @@ class TestProwlerThreatScoreGCP:
output_data.Requirements_Attributes_LevelOfRisk
== PROWLER_THREATSCORE_GCP.Requirements[0].Attributes[0].LevelOfRisk
)
assert (
output_data.Requirements_Attributes_Weight
== PROWLER_THREATSCORE_GCP.Requirements[0].Attributes[0].Weight
)
assert output_data.Status == "PASS"
assert output_data.StatusExtended == ""
assert output_data.ResourceId == ""
@@ -119,6 +123,10 @@ class TestProwlerThreatScoreGCP:
output_data_manual.Requirements_Attributes_LevelOfRisk
== PROWLER_THREATSCORE_GCP.Requirements[1].Attributes[0].LevelOfRisk
)
assert (
output_data_manual.Requirements_Attributes_Weight
== PROWLER_THREATSCORE_GCP.Requirements[1].Attributes[0].Weight
)
assert output_data_manual.Status == "MANUAL"
assert output_data_manual.StatusExtended == "Manual check"
assert output_data_manual.ResourceId == "manual_check"
@@ -142,6 +150,6 @@ class TestProwlerThreatScoreGCP:
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"
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;REQUIREMENTS_ATTRIBUTES_WEIGHT;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;1000;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;10;MANUAL;Manual check;manual_check;Manual check;manual;False\r\n"
assert content == expected_csv

157
tests/lib/outputs/compliance/prowler_threatscore/prowler_threatscore_m365_test.py Normal file
View File

@@ -0,0 +1,157 @@
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 (
ProwlerThreatScoreM365Model,
)
from prowler.lib.outputs.compliance.prowler_threatscore.prowler_threatscore_m365 import (
ProwlerThreatScoreM365,
)
from tests.lib.outputs.compliance.fixtures import (
PROWLER_THREATSCORE_M365,
PROWLER_THREATSCORE_M365_NAME,
)
from tests.lib.outputs.fixtures.fixtures import generate_finding_output
from tests.providers.m365.m365_fixtures import TENANT_ID
class TestProwlerThreatScoreM365:
def test_output_transform(self):
findings = [
generate_finding_output(
compliance={"ProwlerThreatScore-1.0": "1.1.1"},
provider="m365",
account_name=TENANT_ID,
account_uid=TENANT_ID,
region="",
)
]
output = ProwlerThreatScoreM365(
findings, PROWLER_THREATSCORE_M365, PROWLER_THREATSCORE_M365_NAME
)
output_data = output.data[0]
assert isinstance(output_data, ProwlerThreatScoreM365Model)
assert output_data.Provider == "m365"
assert output_data.Description == PROWLER_THREATSCORE_M365.Description
assert output_data.TenantId == TENANT_ID
assert output_data.Location == ""
assert (
output_data.Requirements_Id == PROWLER_THREATSCORE_M365.Requirements[0].Id
)
assert (
output_data.Requirements_Description
== PROWLER_THREATSCORE_M365.Requirements[0].Description
)
assert (
output_data.Requirements_Attributes_Title
== PROWLER_THREATSCORE_M365.Requirements[0].Attributes[0].Title
)
assert (
output_data.Requirements_Attributes_Section
== PROWLER_THREATSCORE_M365.Requirements[0].Attributes[0].Section
)
assert (
output_data.Requirements_Attributes_SubSection
== PROWLER_THREATSCORE_M365.Requirements[0].Attributes[0].SubSection
)
assert (
output_data.Requirements_Attributes_AttributeDescription
== PROWLER_THREATSCORE_M365.Requirements[0]
.Attributes[0]
.AttributeDescription
)
assert (
output_data.Requirements_Attributes_AdditionalInformation
== PROWLER_THREATSCORE_M365.Requirements[0]
.Attributes[0]
.AdditionalInformation
)
assert (
output_data.Requirements_Attributes_LevelOfRisk
== PROWLER_THREATSCORE_M365.Requirements[0].Attributes[0].LevelOfRisk
)
assert (
output_data.Requirements_Attributes_Weight
== PROWLER_THREATSCORE_M365.Requirements[0].Attributes[0].Weight
)
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 == "m365"
assert output_data_manual.TenantId == ""
assert output_data_manual.Location == ""
assert (
output_data_manual.Requirements_Id
== PROWLER_THREATSCORE_M365.Requirements[1].Id
)
assert (
output_data_manual.Requirements_Description
== PROWLER_THREATSCORE_M365.Requirements[1].Description
)
assert (
output_data_manual.Requirements_Attributes_Title
== PROWLER_THREATSCORE_M365.Requirements[1].Attributes[0].Title
)
assert (
output_data_manual.Requirements_Attributes_Section
== PROWLER_THREATSCORE_M365.Requirements[1].Attributes[0].Section
)
assert (
output_data_manual.Requirements_Attributes_SubSection
== PROWLER_THREATSCORE_M365.Requirements[1].Attributes[0].SubSection
)
assert (
output_data_manual.Requirements_Attributes_AttributeDescription
== PROWLER_THREATSCORE_M365.Requirements[1]
.Attributes[0]
.AttributeDescription
)
assert (
output_data_manual.Requirements_Attributes_AdditionalInformation
== PROWLER_THREATSCORE_M365.Requirements[1]
.Attributes[0]
.AdditionalInformation
)
assert (
output_data_manual.Requirements_Attributes_LevelOfRisk
== PROWLER_THREATSCORE_M365.Requirements[1].Attributes[0].LevelOfRisk
)
assert (
output_data_manual.Requirements_Attributes_Weight
== PROWLER_THREATSCORE_M365.Requirements[1].Attributes[0].Weight
)
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 = ProwlerThreatScoreM365(
findings, PROWLER_THREATSCORE_M365, PROWLER_THREATSCORE_M365_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;TENANTID;LOCATION;ASSESSMENTDATE;REQUIREMENTS_ID;REQUIREMENTS_DESCRIPTION;REQUIREMENTS_ATTRIBUTES_TITLE;REQUIREMENTS_ATTRIBUTES_SECTION;REQUIREMENTS_ATTRIBUTES_SUBSECTION;REQUIREMENTS_ATTRIBUTES_ATTRIBUTEDESCRIPTION;REQUIREMENTS_ATTRIBUTES_ADDITIONALINFORMATION;REQUIREMENTS_ATTRIBUTES_LEVELOFRISK;REQUIREMENTS_ATTRIBUTES_WEIGHT;STATUS;STATUSEXTENDED;RESOURCEID;RESOURCENAME;CHECKID;MUTED\r\naws;Prowler ThreatScore Compliance Framework for M365 ensures that the M365 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;1000;PASS;;;;test-check-id;False\r\nm365;Prowler ThreatScore Compliance Framework for M365 ensures that the M365 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;10;MANUAL;Manual check;manual_check;Manual check;manual;False\r\n"
assert content == expected_csv