Manage network policy sets
CloudFlow's network policy sets enable you to manage network security rules deployed in virtual private clouds, regions, or accounts, across multiple security controls including AWS SG, Azure NSG, Azure Firewall, and Google Cloud Project Firewall.
Each security control detected from your cloud accounts, subscriptions, and projects is automatically added to a policy set. Add, delete, or edit rules in the policy sets as required, and commit the changes to implement them on the associated controls.
Policy sets with similar rules can be merged into a single policy set from which all rules and rule collections defined on the related controls can be viewed and managed.
Network Policies page
To open the Network Policies page, click the Network Policies icon on the left. By default, the page opens with All Entities selected and displays an overview of all your vendors and policy types.
Network policies tree
The network policies tree lets you drill down into individual virtual network types.
The network policies tree contains the following entities:
Security Control | Account Type | Virtual Network Type | ||
Icon | Type | Icon | Type | |
AWS SG | Account | VPC | ||
Azure
|
Subscription | VNet | ||
Virtual Hub | ||||
Azure Firewall (classic) | Subscription | VNet | ||
Google Cloud Firewall | Project | VPC |
Network tree search bar
Use the network tree search bar to filter the tree and find entries quicker.
Search using partial or whole names of any of the following:
-
Vendors / Policy Types
-
Accounts / Subscriptions / Projects
-
Regions
-
VPCs / VNets / Virtual Hubs
Network policy sets
View network policy sets:
Click on an entity in the Network policies tree to see a list of matching policy sets on the right.
Azure policy sets include two tabs: Azure NSGs policies and Azure Firewall policies.
-
The Azure NSGs policies tab is disabled for Virtual Hubs because Virtual Hubs cannot have NSG policies.
-
The Azure Firewall policies tab is disabled when the Azure VNet does not have a firewall.
Azure Firewall (classic) has its own entry in the Network policies tree.
Google Cloud Firewall policy sets include two tabs:
-
Firewall Policies tab: Shows VPC Firewall rules as well as inherited rules from the Inherited Policies tab that are used by the VPC Firewall
-
Inherited Policies tab: Shows organization-level and folder-level firewall policies
Search policy sets
In the Search Policy box above the list of policy sets, you can filter the displayed policy sets based on search entries.
For each security control, you can search using partial or whole names and descriptions within any of the following:
AWS SG |
Azure |
Google Cloud |
---|---|---|
Account |
Subscription |
Project |
Region |
Resource group |
Google Cloud Firewall name |
VPC |
Region |
|
SG name |
NSG / Firewall policy name |
Filter displayed policy sets
You can filter displayed policy sets to see a more targeted display of the policy sets that interest you.
Each security control type has its own unique set of filters which you can use to refine the policy sets displayed.
Security Control Type | Available Filters |
---|---|
AWS SG |
|
Azure NSG |
|
Azure Firewall |
|
Azure Firewall (classic) |
|
Google Cloud |
Policy set details
Each policy set includes the following areas:
-
For all policy types (except for Azure Firewall and Azure Firewall (classic)): Inbound and Outbound rules are displayed on separate tabs in each expanded policy set
-
For Azure Firewall: Network, Application, and DNAT rules are shown on different tabs
-
For Azure Firewall (classic): Network and Application rules are shown on different tabs
For more details, see Field reference per rule type.
The total number of risk triggers detected at each severity level appear to the right of the policy set name inside circles color-coded by severity level. These totals include risks on both the outbound and inbound tabs.
Click on the risk severity circles to see details of all the risk triggers detected in the policy. For more details, see View risks details at the policy level.
Note: Merged policy sets and policy sets in Edit Mode do not display this information.
See below Check connectivity for the hybrid network .
CloudFlow displays rule usage information for AWS SG, Azure NSG, Azure Firewall, and Google Cloud Firewall.
Note: For more details about unused rules, see About CloudFlow unused rules.
The Last used column displays one of the following:
Date / Message | Description |
---|---|
(Date)* |
The date that the rule was last used if the rule had at least one hit during the configured inactivity period. Note: If log collection fails for one of the projects, an alert icon appears in the column to indicate that this information may not be accurate. Note (for Azure Firewall): Required logs for calculating Last Used information include Network, Application, and DNAT. If log collection is partially enabled, the Last Used information will be based only on data from those logs that are enabled. |
Flow logs disabled |
For AWS and Azure: Flow logs are not enabled for the relevant security control. AWS: See Enable VPC flow logging Azure: See Enable Azure flow logs |
Logs disabled | For Google Cloud: Logs are not enabled. See Enable Google Cloud logs. |
New / modified rule | The rule was either created or modified during the configured inactivity period and has remained unused since. |
No traffic logged* |
The rule was not used during the configured inactivity period and was created or modified before it. Tip: Delete unused rules to keep your policy clean and avoid risk. For details, see Clean up policies. |
N/A (Google Cloud only) | Rules that are not using TCP or UDP protocol. |
Log collection failure | Contact AlgoSec support for assistance. |
*Note (for Google Cloud):
-
Date and No traffic logged refer to TCP and UDP traffic hits only. If additional protocols are in the rule, appears in the Last Used column to indicate the usage information refers only to TCP and UDP protocols / ports.
-
Inherited Rules: If a rule is used in multiple onboarded projects, the Date or message No traffic logged refers to the last time the rule was used in any of the onboarded projects (this includes projects which the user doesn't have permissions to).
You can hover over Risks on policy indicators to see a tool-tip reminder of what their color represents. For example, the color ORANGE represents "High-level risks".
Click on the Risks on policy indicator to see details about rule risks and affected assets. See View rule risks & affected assets.
Note:
-
Severity circles are not displayed in merged policies or when a policy set is in Edit mode. In these cases the Risks column is greyed out (not active).
-
Activating the COMMIT button after making changes (i.e. being in edit mode), displays the risk severity circles again; however,
for both displayed risk severity and total risk severity summary, changes made in the risks associated with a policy will not be seen until the next data collection/analysis cycle has occurred. (Since this cycle occurs every hour, the maximum wait time for update should be ~1 hour.)
Click the Edit button to enter edit mode. The policy set remains in edit mode until clicking Commit or Discard Changes. While in edit mode:
-
The Editing label is displayed at the top of the policy set display
-
The risks column is inactive and risk severity circles are not displayed
-
Available action buttons:
-
Commit
-
+ Add Rule
-
+ Add Collection (only for Azure Firewall (classic))
-
Discard Changes
-
See below Edit network policy rules.
A list of the Azure Firewalls protecting the selected entity in the tree.
Note: If the Azure Firewall selected in the Network Policies tree has no policies assigned to it then this row of information does not appear.
Child policies inherit the rules of the parent policies. For child policies, click the link of the parent policy to see the parent policy rules.
When activated (default), inherited rules used by the Google Cloud VPC firewall are displayed above the firewall rules in the Firewall Policies tab.
When disabled, only the firewall rules are shown in the Firewall Policies tab.
The path to the folder where the policy is defined in Google Cloud.
Target networks are the Google Cloud networks using rules from an inherited policy. Each target network is listed as a combination of its project name and VPC.
-
If there are multiple networks using an inherited policy, a number indicates how many additional networks there are. Click on the number to see a list of the additional target networks.
-
Target networks in projects that are onboarded to AlgoSec appear in blue. You can click on them to open the VPC and view the relevant network policy. (Target networks in projects that are not onboarded to AlgoSec will not have a link.)
-
When a rule is applied on all projects that inherit a particular policy, the "Target networks" column for that rule displays "All networks".
-
Hover over the information icon to see a list of all projects onboarded to CloudFlow that are using this rule.
-
Click on a project name to open the project with its first policy expanded and the selected rule highlighted.
-
View risks details at the policy level
For AWS, Azure, and Google Cloud
See an aggregated view of the relevant risks associated with each policy.
Do the following:
Click on the risk severity level circles of the desired policy set.
A policy set risk popup appears with information about the policy set and a detailed list of all the risks associated with the policy.
Note: For Google Cloud, toggling Show inherited rules on or off affects whether the list of risks includes risks associated with rules that are inherited or not. For more details on the toggle, see Show inherited rules toggle.
The policy risk details include the following information:
Column name | Description |
---|---|
Severity | The severity of the risk (critical, high, medium, low). |
Risk triggers | The number of times the risk was triggered by rules in the policy. |
Risk ID | The ID number assigned to the detected risk. |
Risk title | The name of the risk as it appears in the risks list panel. |
Description | Click the icon to view a full explanation of the nature of the risk. |
Remediation | Click the icon to view a suggested course of action to resolve the risk. |
View rule risks & affected assets
For any rule, you can conveniently view the risk description, the risk remediation suggestion, and all its affected assets.
Do this:
-
Expand the required policy set and click on the risk severity level circle of the required rule.
The Risks tab of the Rule Risks & Affected Assets popup window is displayed, showing the relevant risks (Outbound or Inbound): -
Click on the Affected Assets tab.
The affected assets are displayed.
Merge policy sets
For Azure NSG, Azure Firewall (classic), and AWS SG
Since each detected network policy is assigned its own, individual policy set by default, you'll want to merge similar policy sets together to view and manage them together.
Note:
-
Merging policy sets is only supported within the same policy type. CloudFlow does not support merging policy sets across AWS SG, Azure NSG, and Azure Firewall (classic).
-
For merged policies, risk severity circles are not displayed and the Risks column is greyed out (not active).
Do the following:
-
View the policy sets you want to merge, using the search box to search for similar items. For details, see Manage network policy sets.
-
Expand each policy set to inspect its details and confirm that you want to merge them.
-
Select the check boxes next to each policy set you want to merge, and then click Merge.
Tip: If you have many policy sets to select, use the Select all or Unselect all links above the grid as needed.
-
In the Merge Policy dialog box that appears, enter a name for your new policy set, and an optional description.
Click Merge to merge the selected policies into a single set.
The policy set grid is updated with your new set. For example:
Tip: To dissolve your merged policy set and return each policy to its own individual set, commit or discard any changes made, and then edit the properties for your merged set.
For details see Edit policy set properties.
Rules that are installed on multiple security controls in merged policy sets each have their own downward arrows. Click on these to view details about each target.
When rule displays are expanded by clicking on the downward arrow, the Installed on column indicates the names of each security control on which the rule is installed.
The columns you see may differ, depending on the type of security control or asset you are working with. For more details, see Field reference per rule type.
For example:
Edit policy set properties
For Azure NSG, Azure Firewall (classic), and AWS SG
Edit the properties for each policy set to change the name, description, or member security controls.
Note: If you want to add or modify policy rules, drill down into the policy set itself.
If your policy set is currently in Edit mode, you will not be able to modify the policy set properties. Commit or discard your changes to make these edits.
For more details, see Edit network policy rules.
Do the following:
-
View the policy set whose properties you want to edit.
Tip: You may want to use the search box to find the one you're looking for. For details, see Manage network policy sets.
-
Click the properties button next to the policy set name.
-
In the Network Policy Set Properties dialog that appears, do any of the following:
Name Edit the name listed for the policy set in the grid. Description Enter a description for the policy set. This description is shown in the grid when you hover over the Description icon. Security Controls This area lists the security controls included in the policy set.
- Click an X to remove a single security control from the set.
- To completely dissolve the set and return each policy to its own individual set, click Clear all controls. In the message that appears, click Yes to confirm.
Tip: To add a new security to control to a policy set, merge the relevant sets together. For details, see Merge policy sets.
Edit network policy rules
For Azure NSG, Azure Firewall (classic), and AWS SG
Edit each of your network policies by adding, deleting, and modifying rules and rule collections in the network policy set.
-
Any changes made in a specific rule affect all security controls where the rule is installed.
-
Only one user can edit each policy set at a given time. Policy sets are locked while editing and are opened in read-only mode by default.
When you're done, click Commit or Discard changes to unlock the policy set for others.
For Azure Firewall (classic) only: Once a rule collection is created, its priority, name, and action are all read only. The rules inside a rule collection, however, can be edited.
Note: If you want to make higher-level changes, such as the policy set name, description, or member controls, view the policy set from its parent level. For more details, see Edit policy set properties and Manage network policy sets.
Do the following:
-
Browse to and expand a specific network policy set. For details, see Manage network policy sets.
Rules are displayed in a boxed grid that lists the source, destination, and protocol details for each rule, as well as the security controls each rule is installed on.
If you are in read-only mode, a large Edit button is shown at the top right of the policy set box. Click the Edit button to make changes to the expanded policy.
Note: For Azure Firewall (classic), the rules are grouped by rule collection. Expand the collection to drill down to rule details.
- Do any of the following:
-
At the top of the boxed grid, click + Add Collection.
-
Enter a unique name and numeric priority, and then define an action for the new collection: either Allow or Deny.
For example:
-
Click Done to add your new collection.
-
At the top of the boxed grid, click + Add Rule.
-
In the New ... Rule dialog that appears, populate the fields as needed.
-
Click Done to save your rule.
The new rule appears within the dropdown list for the selected collection.
-
For Azure Firewall (classic) only, find your collection in the policy set and click the dropdown arrow at the right side of the row.
- Click on one of the Edit or Delete icons to the right of the target rule.
Edit An Edit ... Rule dialog opens for the rule you selected to edit. Make your changes as needed, and click Done . Delete. The rule is removed from your policy set. Tip: For Azure NSG and AWS SG with flow logs enabled, CloudFlow displays the date each rule was last used, if at all.
You may want to delete unused rules to keep your policy clean. For details, see Clean up policies.
The page is refreshed with your changes.
-
Do one of the following:
-
Click Discard changes to revert back to the last saved version of the policy set and unlock it for others.
-
Click Commit at the top of the screen to save your changes.
CloudFlow displays a list of the changes you made. Accept the changes to complete the commit.
The commit provisions your changes on the security controls and unlocks the policy for others.
-
Azure Firewall (classic) organizes its rules by rule collections. For more details, see Field reference per rule type.
Do the following:
Within your new collection, click + AddRule to create a new rule with the selected collection already defined. For more details, see Add a new rule.
Note: In Azure Firewall (classic), when rules are defined within a rule collection, each rule inherits the priority and actions defined for the parent collection.
Do the following:
To edit or delete an existing rule, do the following:
Note: Your changes are automatically saved, even if you haven't committed them, closed your browser or logged out of CloudFlow. They will be there for you the next time you browse back to this policy set. However, the policy set remains locked for others until you commit or discard your changes.
Check connectivity for the hybrid network
For Azure NSG Policies
Note: ASMS Integration, a one-time task, needs to be executed before connectivity can be checked for the hybrid network. See ASMS integration to SaaS services
The connectivity check runs a traffic simulation query on ASMS with the subject rule fields (source, destination and service). Cloud-specific elements (e.g. service tags, Virtual Network, ASG, etc.) are translated to the IP-equivalent content based on the target NSG configuration.
The connectivity check in CloudFlow allows you to observe how traffic is routed and whether it’s allowed across your entire hybrid network (that is, across NSGs, firewalls routers etc. deployed on cloud and/or on-prem).
if a subject NSG has a rule with “VirtualNetwork” or “Any” in its destination, CloudFlow will map the destination to the address space of the VNET containing the subject NSG and put that in the destination field when running a traffic simulation query against ASMS.
In CloudFlow, you can see the details of your Azure NSG policies which describe what is allowed by the NSG policy rules.
After establishing trust with your ASMS host, you can check connectivity within your hybrid network.
To run a connectivity check
Here are some points to remember when running Connectivity checks:
-
A connectivity check result link is available for 12 hours and visible to all users viewing the subject policy set.
-
If theConnectivity icon is disabled (grey), hovering over it will display the reason this connectivity check cannot currently be performed.
-
If the connectivity icon animation is active, the connectivity check is in progress, wait for results.
-
The connectivity check may take up to an hour, depending on how wide or narrow the rule fields are.
-
When a rule can be expanded using the downward arrow on the right side of the screen, you must expand it and run connectivity on each NSG separately.
Note:
-
An NSG rule containing a Service Tag that has no IPs- AzureLoadBalancer, GatewayManager
-
An NSG rule containing an ASG (Application Security Group) is not connected to any NICs (Network Interface Controllers)
-
An NSG rule containing a “VirtualNetwork” in the source or destination, while the VNET has an address space but no actual IPs within (e.g. no VMs).
-
An NSG that is not attached to any subnet or NIC.
Do the following:
-
In the policy set details, click the enabled (blue)Connectivity icon of the in the Risk column of rule you want to check.
Reviewing connectivity check results
On the CloudFlow Azure network policy page from where the connectivity check is initiated, results are color-coded according to this legend:
Partially Allowed - Some traffic is allowed and some is blocked by the devices in the query path. |
|
Allowed - All traffic is allowed by all the devices in the query path. |
|
Blocked - All traffic is blocked by all the devices in the query path. |
Hover over the information icon next to any Results link for further details.
You should be able to login to the connected ASMS instance from your browser.
When you click on the connectivity check result, if you are not yet logged-in to ASMS, you will be directed to do so.
Connectivity checks display the matching ASMS traffic simulation query results in a separate browser tab where all standard ASMS traffic simulation query functionality is available.
Change detection from outside CloudFlow
When changes are detected in a security control managed by CloudFlow, CloudFlow merges the changes into any relevant policy set.
CloudFlow attempts to merge the changes even if the relevant policy set is currently in draft mode or being edited by another user. These changes are reflected in the network policies page when it is freshly accessed. If the network policies page is already open in a browser tab, you may need to refresh it.