About Policy Generation applications tables

When opening the Applications page for the first time, the tabs are blank until Policy Generation is set up and running.

The Action Steps panel on the right side of the page lists the five action steps to process raw, unsecured workloads into applications in a fully microsegmented and protected security fabric.

Using machine learning, Policy Generation:

1. Discovers all connections between your workloads and identifies the functions of all the workloads and their interconnections.

2. Groups discovered workloads into proposed applications and application tiers, proposing tags for the workloads: Tier Function, Deployment Environment, and Application Name.

3. Provides risk scores for workloads, tiers, and applications to help you see what is most at risk.

4. Proposes ACL rules that permit observed traffic between tiers.

5. Helps to systematically review, edit, approve, and deploy each proposal.

6. Helps to microsegment or segment workloads, in preparation for enforcing policy rules.

7. Tests the deployment on actual traffic, for a second review and edit.

8. Adds a security tag to the application workloads, enforcing policy and only permitting traffic that your ACL rules allow.

Setup Policy Generation

STEP 1: Discover connections

Click SETUP POLICY GENERATION to open the configuration wizard to set the automated processes in motion. Fill out the forms on the tabs and refer to the help provided on each page. Click DONE in Setup Policy Generation to begin connection discovery.

The graph in Step 1 shows a status of RUNNING and the time and date it started.

A status message displays, for example, “The first results will appear at 05:09 PM.” This is the time discovery will stop, but it might take longer for the first data point to appear on the chart. Connection data is displayed in the graph in Step 1 after each 2-hour discovery cycle, plus computation time. Even after just the initial discovery cycle, FortiPolicy will begin proposing applications and policies.

However, this is not the time to begin approving or deploying applications.

Allow Policy Generation to discover all network connections and propose applications and ACL policy rules.

Most connections are discovered in the first cycle. Some connections, however, will take longer. For example, if your backup only runs on Sunday night. Let the discovery process run until all the allowed connections have occurred. The graph adds a data point every 2 hours until there are no more new connections discovered. At 0, Policy Generation is not seeing any NEW connections. Wait until there are several consecutive updates at 0.

When the graph in Step 1 stabilizes at 0, this means you can move to Step 2.

If there are rare connections that might not take place until the distant future, you can manually add them in later.

STEP 2: Deploy applications

In Action Step 2 - Deploy Applications, click START.

The deployment wizard displays the Application Details page and will first walk you through deployment of each of the proposed common network services, then the deployment of each of the proposed business applications.

Common Services: Review, edit as needed, approve, and deploy all the proposed common network service applications (such as DNS and NTP) before approving and deploying proposed business applications. A business application cannot be deployed until its common services are deployed. While reviewing a business application, the wizard can deploy needed common services when necessary, but in the middle of reviewing a business application, you will lose the ability to carefully review and edit those services that are not already deployed.

The wizard displays the Application Details page for each common service. The page allows you to examine, edit, approve, and deploy each proposed common service application. Follow the on-screen help to process the proposal and deploy the rules you approve to the root FortiGate’s security fabric.

Business Applications: After you deploy all the common services, the wizard displays the first business application. At this point you have two options:

• Follow the Wizard - Let the wizard walk you through deploying the proposed business applications, just as it did for the common service applications.

• Make Your Own Choices - To decide for yourself which business applications you want to secure first, click CLOSE on the Application Details page. The system will return you to the All Applications table showing you all proposed business applications and deployed common service applications.

The Applications page has tabs across the top of the page. Three tabs are for:

• All Applications

• Common Services

• Default

Plus, one tab for each deployment environment specified in the Setup Policy Generation wizard:

• Production

• Development

• Test

• Staging

• PCI

Policy Generation populates these tabs with proposed applications. When you set up Policy Generation, you had an opportunity to provide data that might help the system identify what deployment environment a workload serves. If that data is not available, Policy Generation chooses the Default environment.

Each tab has two views: Application Tables and Application Topologies.

• The Application Tables (default view) display details of all the proposed applications in each tab. Each application has a summary row that can be opened to show summary details of each tier in the proposed application. If, on the FortiGate, you enabled Layer-7 discovery in the ACL rules that are providing flow data, then there will be a risk score for each application and tier. Click on the numeric score link to display risk and vulnerability data if it is available.

  An action menu on the far left of each table row displays the actions that can be taken on each proposal appropriate to its step in the process.

• The Application Topologies let you easily see which applications are connected to other applications. Select the map icon in the upper right corner of the Applications page for the Topology view. Select the connection between two applications to view the proposed ACL rules that connect them.

  Each application rectangle on the topology has a tier count link and number indicating its stage in the process. Next to the number is a drop-down arrow, which displays the proposal’s status and the menu of actions that can be taken on each proposal, appropriate for its step in the process.

Choose An Application to Secure: Search and sort the table or search and scan the topology to find the business application you want to secure next.

You might want to search for workload names or IP addresses that you know belong to a specific application. Click the application name in the table or click the tier count link in the topology to open the Application Details page.

Approve & Deploy: The Application Details page lets you examine, edit, approve, and deploy the proposed business application, just as you did with the common service applications. Follow the on-screen help to process the proposal and deploy the rules you approve to the root FortiGate and its security fabric.

Approve & SAVE: The Application Details page supports an alternate workflow if you want to have multiple reviews before deploying rules to your security fabric. When the last of all the proposed tiers and ACL rules are approved, you are given the choice to deploy now or save and deploy later. If you choose to deploy later, your work will be saved and others can review your work. When the application has passed the requisite reviews, you or another authorized user can deploy the application to the security fabric.

Approve & Deploy to an Alternate ACL table: Remember that there is another alternate workflow: If on the Scope tab of the Setup Policy Generation wizard, you selected an alternate access control policy that was not assigned to the security fabric on the Configuration > Security Fabric page, then each time you “Deploy” an application, its rules are saved to the alternate ACL policy table, and not to the security fabric. This gives you and your team the opportunity to review the whole ACL table. When the whole alternate table has been reviewed and accepted, you can then associate the alternate ACL with the security fabric and deploy the ACL rules to the security fabric.

Steps 3 through 5 require that the security rules are deployed to the security fabric.

STEP 3: Insert deployed applications

Insertion is the process of configuring the security fabric to monitor and regulate an application’s traffic and it is dependent on the ACL rules being deployed to the security fabric. Insertion is a perquisite for the next two action steps.

FortiPolicy applies two types of insertion that are facilitated using FortiGate’s LAN segment feature:

• Microsegment essentially puts a firewall around every workload, even those on the same subnet or in the same application tier. All traffic is now monitored and controlled by a FortiGate. When later enforced, the rules that you have deployed will govern what workloads can talk to each other and what traffic will be blocked.

  Once they are deployed to the security fabric, you can microsegment all deployed business applications, and common services applications in bulk by clicking INSERT at Step 3: Microsegment. Such deployed applications can also be individually microsegmented by selecting Microsegment on their individual application action menus.

• Segment puts a firewall around every application tier. When later enforced, the FortiGate can then monitor and control all traffic between tiers. Traffic within tiers is NOT controlled when a tier is segmented.

  Applications are individually selected to be segmented by selecting Segment on their application action menus

You might want to wait for inserting deployed applications to allow team members to review your work.

Insertion Staging allows you to queue one or more deployed applications for insertion. You can queue some applications to microsegment and others to segment. Later you can batch insert the applications in the queue, while leaving others to be inserted later.

To queue an individual deployed application for insertion, click to open the application’s action menu from the application’s table or topology. Then click the insertion type you want from the action menu: Microsegment or Segment.

Each time you select an insertion type for an individual deployed application, the system will increment the Insertion Staging link near the top right of the Applications page. This indicates that the application has been placed into the Insertion Staging queue. You can view the queue at any time by clicking on the Insertion Staging link. Insertion Staging is located at Workspace > Grouping > Insertion Staging.

Applications placed into Insertion Staging are queued for the insertion type you selected.

To be selective, click COMMIT ALL CHANGES on the Insertion Staging page. This executes all insertions specified in the Insertion Staging queue, whether microsegment or segment. Deployed applications that have not been queued will NOT be inserted.

To microsegment in bulk, click INSERT at Step 3: Microsegment. This will:

• Microsegment all deployed applications that are NOT in the Insertion Staging queue.

• Execute all insertions specified in the Insertion Staging queue, whether microsegment or segment.

The Insertion Progress bar in Step 3 tracks insertions. You can also track insertions from the Workspace > Logs > Jobs page.

• If you want to remove insertion for one application, open that application’s action menu on the Applications table or topology and click Revert Insertion. If the application has been enforced, click Revert Insertion & Enforcement. This will place the application into Insertion Staging. Click COMMIT ALL CHANGES on the Insertion Staging page to complete the process of reverting insertion for individually selected applications.

  If you want to remove all types of insertion for all deployed and inserted applications, click Revert at Step 3: Microsegment. This will revert all applications to the not inserted state, including any individual applications in the Insertion Staging queue.

Resource groups

Resource Groups are discovered workloads or subnets with members selected according to their shared or similar security requirements. When workloads enter or leave your environment, the Resource Groups are automatically updated to reflect the changes.

You can use Resource Groups as sources and destinations in ACL rules or as filters in Setup Policy Generation.

To add a new resource group from the Workspace > Grouping > Groups page or the Setup Policy Generation Filters tab, select the Add Resource Group plus sign icon button:

• In the Add Resource Group page, enter a Name and Description for the new Group.

• Membership Rules are logical filters you create to define groups of workloads or IP addresses. The membership of Resource Groups is not static. When there are changes in your environment, membership is adjusted automatically, based on your rules.

• The Workloads table initially lists all workloads discovered in your security fabric for which you have created data planes. You can sort the table to find examples of the workloads you want to include in your new group.

• To create a membership rule:

  • FortiPolicy Tag is NOT an appropriate choice for Filters.

  • Native Tags will be supported in a future release.

  • Choose a CATEGORY: Workload Name, Port Group/Subnet, Subnet, FortiPolicy Tag, or Native Tag.

  • Choose an OPERATOR: Is, Contains, or Begins with.

  • Enter a filter string or integer VALUE, for example: 'dbtier'.

• If you choose the Subnet category, you are specifying endpoints outside the examined network, and no Workloads table is presented.

• If you choose Workload Name, Port Group/Subnet, or FortiPolicy Tag for the category, you will see the Workloads table.

• Click PREVIEW after defining membership rules to filter the Workloads table by the membership rules. This shows you which workloads match the rules.

• Click the Add Rule icon button to add an additional rule.

• When the PREVIEW in the workloads table matches the full set of workloads that you want in the Resource Group, you are finished with creating membership rules.

• If you are creating a Filter Resource Group in Setup Policy Generation > Filters, then your task is complete, and you can click SAVE.

• If you are adding the Resource Group to be a source or destination in an ACL rule, then click Enable and choose the Insertion Type to be used by Fortinet for monitoring and securing the Resource Group members you have selected: No Insertion (the default insertion type), Segment, or Microsegment.

• Click SAVE.

When you click SAVE, any Resource Group with Segment or Microsegment insertion is sent to the Insertion Staging page to await your further insertion action. View the configured Resource Group(s) in the Insertion Staging page. From Staging, you will need to commit the insertion changes by selecting the COMMIT ALL CHANGES button.

All Resource Groups are listed in the Resource Groups table on the Workspace > Grouping > Groups page. Deployed application tiers are also resource groups, and they too will appear in the Resource Groups table. Tiers can also respond dynamically to changes in the workload members of your security fabric. If new workloads appear and you have used FortiPolicy API endpoints to tag those workloads, they will automatically join any existing tiers with that tag set, and the tier’s ACL rules will be applied to the new workload tier members.

Step 4: Test policy rules and resolve violations

Now you can test your ACL rules that have been deployed to and inserted on the security fabric against live traffic on your fabric, without blocking any traffic until you want to enforce them. Testing will flag any traffic that does not conform to your rules. You can then review these rule “violations” and select one of the following:

• Acknowledge as violations: This is suspect traffic that you will want to block when you secure your application. This traffic violates your rules and you do not want to allow it.

• Acknowledge as legitimate: This is valid traffic that either was not detected during connection discovery at step 1 or that you might have edited out while approving and deploying the application. Now that you are testing against live traffic, you recognize that you should allow this traffic by adding an ACL rule.

Here you have an option to test all deployed and inserted applications in bulk or be selective about which applications to test when.

To test all deployed and inserted applications: In Action Step 4 Test Policy Rules, click TEST.

To test only selected deployed and inserted applications: Select the applications’ action menu on the Applications table or topology. Click Test ACL Rules for each application to test.

When application testing starts, the first start time is displayed under the Action Step 4 Test Policy Rules. When the testing system starts, it processes packets against the rule table. All unsecured traffic is allowed to pass. Packets for which there are no rules are:

• Recorded as violation events

• Displayed in the Unresolved Violations chart every five minutes

• Summarized into unique violation types every hour

Click RESOLVE VIOLATIONS to view a Unique Violations page with a table row for each unique violation. Follow the on-screen help on this page to determine if you want to add an ACL rule to allow this traffic or just acknowledge that you want to block such traffic when you enforce security at Action Step 5.

Resolve Violations

Policy Generation compares all packets transmitted since the last time the policy table changed with all the ACL rules for deployed and inserted applications. All packets that match an ACL rule will be set to ALLOW the connection. All packets that DO NOT match an ACL rule will also be allowed. However, they will be logged as a violation of the deployed ACL rules. Multiple packets that are from the same source to the same destination with the same port and protocol will be logged as a single unique violation. Every 5 minutes, the Unresolved Violations chart will record the total number of unique unresolved violations that occurred in that 5 minute period.

The Acknowledged progress bar at the top of the table shows you how many of the unique violations have been acknowledged.

Each row in the chart presents a summary of one unique violation:

• Start is the detection time of the first packet from the Source to the Destination, using the Protocol and Destination Port.

• The Hit Count is the number of times that this same connection was detected.

• Click the Events icon to bring up the Violation Events Details page listing all the identical violation events over time.

To allow a connection and resolve a unique violation by adding an allow rule, click the Add Rule icon to bring up a the Add ACL Rule dialog. This displays a proposed allow rule preconfigured to match the violation. You can make notes in the Description field at the end of the rule. Select SAVE to create the new rule. Creating the new rule in this way will automatically check the Acknowledged checkbox for the unique violation and increment the Acknowledged progress bar.

To block a connection from the Resolve Violations dialog, check the Acknowledge checkbox for that row on the Unique Violations table. No rule is created. When you later secure the application, this violation will be blocked.

To block many connections, use the Select All checkbox at the top of the page. You can then deselect any rows you do not want to block, click the Add Rule icon to bring up a the Add ACL Rule dialog for each row you want to allow, and then select SAVE.

When all the violations are resolved and new ones are no longer appearing, you may select END TESTING to stop testing and proceed to STEP 5: Secure.

If you want to resume testing later, you can do so from the Applications table or topology by selecting the action menu item "Test ACL Rules" on individual applications.

STEP 5: Enforce security policies

You can now enforce all deployed and inserted ACL rules, or you can choose to only enforce the rules for selected applications.

• To enforce ACL rules for one deployed and inserted application at a time:

  • Click the application’s action menu on the Applications table or topology.

  • Click Enforce ACL Rules.

  That application is now secure!

If at any time you want to stop enforcing a single application’s ACL rules, click Revert Enforcement on the application’s action menu.

• To enforce all ACL rules for all deployed and inserted applications, click ENFORCE POLICY at Step 5: Secure.

All your applications are now secure!

If at any time you want to stop enforcing all applications’ ACL rules, click Revert at Step 5: Secure. To revert enforcement for Individual applications: Click Revert Enforcement on its action menu.