You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Firewall logging is not enabled. Firewall logs can help to detect threat actors and to investigate security events. Therefore, it is recommended to have it enabled by default in productive VPCs
Rational
Firewall rules or policies are critical for providing network security by defining rules for traffic incoming and outgoing from your network. Therefore, it is critical to audit and verify that deployed firewall rules or policies are working as intended by auditing what connections are denied and allowed. Firewall logs can be used as a source of network forensics in the case of an incident. Security Command Center Event Threat Detection can use firewall logs to detect threats. Firewall logs are also very helpful in debugging firewall rule and policy issues.
Recommendation
It is recommended to implement firewall rule and policy logging especially for:
sensitive networks so that it can be verified that your firewall rules are functioning as expected.
the deny ingress and egress rule so that you can audit traffic attempting to enter and leave the network but blocked by the firewall.
Consideration: Firewall rule logs have standard Cloud Logging costs associated with them. Firewall logs can be enabled in production, but not in non-production if cost is more of a concern than network forensics. Firewall logs in non-production can be enabled when needed to debug firewall issues.
Expected behavior
Firewall rules should have logging enabled by default. There can be the option to actively opt-in to disable the logs to save costs. This option should have a comment that it is only recommended in non-prod environments.
The text was updated successfully, but these errors were encountered:
From my point of view, we shouldn't blanket-enable logging for every firewall rule in FAST.
FAST is meant to bootstrap a landing zone, and the explicit assumption is that it needs to be configured to meet specific production requirements, including the desired security level and related spend. As such, blanket enabling logs on every firewall rule will force users to a) bear the cost, or b) edit every rule to disable logging where it's not wanted and this will introduce friction.
What we should do instead, is provide an opinionated default where sensitive rules like SSH ingress have logging enabled, and broad rules like ICMP or ingress for health checks are kept with logging disabled.
Describe the bug
Firewall logging is not enabled. Firewall logs can help to detect threat actors and to investigate security events. Therefore, it is recommended to have it enabled by default in productive VPCs
Rational
Firewall rules or policies are critical for providing network security by defining rules for traffic incoming and outgoing from your network. Therefore, it is critical to audit and verify that deployed firewall rules or policies are working as intended by auditing what connections are denied and allowed. Firewall logs can be used as a source of network forensics in the case of an incident. Security Command Center Event Threat Detection can use firewall logs to detect threats. Firewall logs are also very helpful in debugging firewall rule and policy issues.
Recommendation
It is recommended to implement firewall rule and policy logging especially for:
Consideration: Firewall rule logs have standard Cloud Logging costs associated with them. Firewall logs can be enabled in production, but not in non-production if cost is more of a concern than network forensics. Firewall logs in non-production can be enabled when needed to debug firewall issues.
Expected behavior
Firewall rules should have logging enabled by default. There can be the option to actively opt-in to disable the logs to save costs. This option should have a comment that it is only recommended in non-prod environments.
The text was updated successfully, but these errors were encountered: