Overview

Connecting FortiPolicy to your security fabric automatically loads data on all the fabric’s workloads into FortiPolicy. This can be confirmed on the Insights > Workloads dashboard and the Insights > Maps views.

Configuring Policy Generation initiates a deeper process of discovery and analysis of all those workloads connections, which will automatically present you with a complete security policy proposal. The Action Steps then guide you through the process of reviewing, editing, approving, deploying, microsegmenting, testing, and enforcing security policies on your security fabric.

Policy Generation groups workloads into applications, application tiers, and deployment environments, like production and development, so that the sources and destinations in your deployed ACL rules are easily identified with the functions and roles they enable in your network.

Setting up Policy Generation

Policy Generation will discover all the traffic between all the workloads and endpoints in the network. Using that data, Policy Generation will automatically organize your workloads into proposed applications, application tiers, and ACL rules. The more you complete on the setup page form, the more work Policy Generation can do for you. The six tabs let you specify:

• Scope: Where to look for connections and how to process the data.

• Public IPs: The public IP addresses that are to be analyzed as part of your infrastructure.

• Filters: Logical rules to limit the scope specified on tabs 1 and 2.

• Names: Your workload naming convention so the system can name applications, tiers, and deployment environments for you.

• Tags: How to name Applications, Application Tiers, and Deployment Environments and how to tag workloads.

• Services: The names of Common Network Service applications that support networks and the ports and protocols they use. Identification of network services is crucial to deriving the optimal set of business applications.

Select the information icons on each tab to view detailed instructions.

When all six of the setup tabs are completed as best you can, click DONE on the SERVICES tab.

Click the Setup Policy Generation button in the Action Steps panel on the right side of the Workspace > Applications page to fill out the form on the wizard and start the set up process.

Scope

Here you specify from where and how Policy Generation should gather data on the connections with and between workloads, and where to store the policy rules that will result from your review and deployment of the automated policy proposals.

• Security Policy Set:For the Security Policy Set dropdown list, keep the default setting as Discover.

• Access Control Policy: Select the policy table in which you want to store the ACL rules. Typically, this will be the Default ACL Policy. If you previously created another policy table for this purpose, select it here. Note that selecting a policy table assigned to the security fabric populates the security name to the right of the Access Control dropdown.

  When you configured the security fabric, you associated it with a policy table. In the Policy > Access Control page, you have the option to create another policy table that you can select here. If you select a policy table that is not tied to the security fabric, no fabric name will be displayed. This configuration will let you deploy ACL rules to the new table, but those rules will NOT be forwarded to the security fabric until you associate the new policy table with the fabric on the Configurations > Security Fabric page.

• Fortinet Security Fabric: Be sure that the checkbox in front of the name of your security fabric is selected. This allows Policy Generation to gather data from the security fabric.

This completes the first page of Setup Policy Generation.

When finished, select the Next button or the Public IPs tab.

Public IPs

Enter any public IP addresses that you want to be analyzed as part of the network you want to secure.

If Policy Generation observes a public IP address that you entered, then Policy Generation will propose an application tier that is specifically defined by that public IP Address.

If Policy Generation observes a public IP address that you have NOT entered to be analyzed as part of the network you want to secure, then Policy Generation will propose a generic, all-inclusive tier with the universal IP range 0.0.0.0/0. The specific observed public IP address will be listed in the tier details as observed, but the tier definition will include all IP Addresses, public and private.

When finished, select the Next button or the Filters tab.

Filters

Policy Generation will examine all workloads defined on the Scope tab and the Public IPs tab, unless you add one or more filters.

Add Include filters to specify which of the defined workloads and subnets to examine. This is a way to narrow the scope.

To further narrow the scope, add Exclude filters to specify which of the defined or included workloads and subnets already specified, should NOT be examined.

When finished, select the Next button or the Names tab.

Names

Policy Generation proposes names for application workload tiers based on their:

1. Application Name: For instance, CRM, Accounting.

2. Deployment Environment: For instance, Production, Development, Testing

3. Tier Function: For instance, Web, Database, Application Logic

If applicable select one of the two naming convention patterns that best fits your workload naming configuration.

If your workload names do not provide any of these three data values, in a pattern that Policy Generation can read, then select the None radio button

FortiGates do not currently support a native tagging system.

When finished, select the Next button or the Tags tab.

Tags

Policy Generation uses its own Key/Value tags to identify the membership of workloads in applications, tiers, deployment environments, and their functions. FortiPolicy groups workloads by their function and connections. It proposes applications, tiers, and policy rules that support the examined traffic.

On this page there are three sub-tabs, one for each of these three categories of data.

If your naming convention provided Policy Generation with Application Name data, you will see the values for all your applications pre-populated in double columns on the first of the three sub-tabs.

If all your users are comfortable using the strings in your naming convention, you do not need to change anything. Many companies have so many applications that some users will not know all the application tag values. You can help those users by supplying full names as well as briefer tag values.

For any data that cannot be derived from your naming convention, manually enter the Tag Values and Full Names you will use to identify your applications, deployment environments, and functions.

Many companies have so many applications that some users will not know all the application tag values. You can help those users by supplying full names as well as briefer tag values.

Each tier is typically defined by a set of three workload tags. For example:

Tag Key	Values	Full Name
SX_Application	Acnt	Accounting Software
SX_Application	Inv	Inventory Management
SX_Environment	Prod	Production
SX_Environment	Test	Test
SX_Environment	Dev	Development
SX_Tier	Web	Web
SX_Tier	Logic	Business Logic
SX_Tier	DB	Database

If your workload naming convention provides any of this data in a supported format, Policy Generation will automatically read all the workload names and populate the Tags forms. All you might want to do is edit the Full Names for each of the tag values. If you do, the Full Names will be used in dropdowns and table labels instead of the typical brief naming convention values.

For any data that cannot be derived from your naming convention, on each of the three sub-tabs you can enter the Tag Values and Full Names you will use to identify your applications, deployment environments, and tier functions.

When finished, select the Next button or the Services tab.

Services

It is vitally important to help Policy Generation identify all Common Network Service applications, like DNS and NTP, that tend to interconnect all the Business Application tiers in your environment.

The Services page presents a list of many of the most common such services with their standard names, ports, and protocols. If your network uses nonstandard ports and protocols for any of the listed services, you need to edit each such service to include all its ports and protocols.

Add any custom services in your network that are not already on the standard list.

In this way, Policy Generation will be able to better distinguish between the following:

• Business application tiers that are connecting within a business application or to other business applications

• Service tiers that are speaking to each other and to most of the business application tiers

If you have completed all the other tabs in the Setup Policy Generation wizard, select DONE to submit any Services edits, close the wizard, and return to the Applications main page, where you will see that connection discovery has started.

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.

Prerequisites

Installation: Complete the installation process as described in the FortiPolicy Getting Started Guide.

License: Go to Configuration > License and import your FortiPolicy license.

Security Fabric: Go to Configuration > Security Fabric and connect to the root FortiGate of your security fabric. On the root FortiGate, authorize the connection to FortiPolicy.

Layer-7 Data: While on the root FortiGate, enable layer-7 discovery on existing ACL rules that are providing flow data. FortiPolicy displays the fabric workloads in its Workspace > Asset Map and lists them for discovery. FortiPolicy then proposes allow rules that allow specific data to flow from one specific place to another. Data that is not allowed by any rule is blocked.

Data Planes: Go to Configuration > Data Planes and create a data plane for each FortiGate with connected workloads that you want to secure.

Setup Policy Generation: Go to Workspace > Applications > Action Steps and click SETUP POLICY GENERATION.

Applications Action Steps

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 can't 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: Table and Topology.

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:

  • Note that FortiPolicy Tag is NOT an appropriate choice for Filters.

  • Note that 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.

About the Application Details page

The Application Details page has four main sections:

• Application header bar that identifies the proposal and its status and provides a toolbar.

• Map view that graphically presents all the proposed tiers and connections.

• Members table that shows the workloads, subnets, or ACL rules of the object selected in the Map.

• ACL table that displays all the proposed ACL rules for the application in one table.

Approve and deploy proposed applications

Policy Generation automates the creation of proposed access control policies based on actual network traffic.

The purpose of the Applications Details pages is to allow knowledgeable users to review and edit as necessary, each detail of a proposed application policy. Are the names, groupings, and ACL rules appropriate to identify and protect valid network functions?

• Application Name

• Deployment Environment Name

• Tier

  • Count

  • Membership

  • Function

  • Name

  • Description

• Connection ACL Rules

  • Source

  • Destination

  • Port

  • Protocol

  • Name

  • Description

The Application Details page takes you systematically through each detail so that you have control of and confidence in the security policies you deploy on your network.

Click START on the Workspace > Applications > Action Steps panel to begin the deployment wizard. The wizard takes you through each of the Application Details pages of the proposed Common Network Service applications. Any security risks in these services can create risk throughout your network. Review and deploy these services first since all business applications are dependent upon them.

Common Network Service Application Names: Usually the data you provided on the Services tab of the Policy Generation Setup wizard is enough for the system to accurately identify your network service application names, but you may want to edit them in ways that conform to your liking and needs. You can edit the name of the service tier as needed.

Common Service Deployment Environments: By default, all proposals are assigned to the Default environment, unless you were able to provide naming guidance in the Policy Generation Setup wizard. You might have some applications in your Production environment and other instances of the same applications that serve your other environments like Test and Development. You will need to determine what deployment environment each proposed application belongs in. If you have common services that support multiple environments, you might decide to leave them in the Default Environment or create a special deployment environment for these shared resources: Go to Applications > Edit Setup > Tags > Deployment Environments to create new deployment environment names that can then be selected from the dropdown list on the Application Details pages..

Common Service Tier Function: Each service tier is assigned the Service function by default. You do not need to change this function.

Approve Service Tier: A tier may be composed of a single server, a server cluster, or a set of independent servers or clusters. Review the proposed tier members. Do they have the same security requirements, and do all indeed provide the service identified in the Application Name? You may decide to delete a member from one tier and add it to another tier in another application. When you are happy with the Application Name, Deployment Environment, tier Function, Tier Name, and membership, click the Approve Tier button in the lower right corner. The wizard will automatically advance to the next tier to be reviewed or to the first connection to be reviewed.

Approve Service ACL Rules: If the service has connections to other deployed common services, the deployment wizard allows you to approve each connection’s ACL rules before deploying a service application. Review the ACL rule and edit if necessary. When you are happy with the connection click the Approve Policy button in the lower right corner.

Connections between the services and the business applications are reviewed on each business Application Details page.

Approval Complete: When all application tiers and connections are approved, you will see the Approval Complete message, giving you the choice to deploy the application now or later. For the best security, service applications must be deployed before you deploy your business applications. If you are ready to deploy now without further levels of review, then click DEPLOY RULES NOW. The system checks to see if you edited the Application Name and Deployment Environment from Policy Generation’s initial proposal. If you did not make any edits, you will get a chance to make any last changes.

Deploying the proposal will prevent further editing of the proposal as a whole and send the rules to the security fabric.

Workload Tags: When you deploy any application, the workloads in that application are tagged with the following FortiPolicy tags based on the choices you approved and deployed:

• Application Name tag

• Deployment Environment tag

• Tier Function tag

• Secure tag

  • The Secure tag defaults to “No” but is switched to “Yes” when you choose to secure the application.

If your process requires additional review, then click DEPLOY LATER. Reviewers may select fully approved common service applications from the Applications tables or topologies. To follow the best security practices, you will need to complete all service application policy reviews and deploy your service applications before approving and deploying any business applications. When you return to a fully approved service Application Details page, you will see the DEPLOY RULES button in the lower right corner. Click DEPLOY RULES to deploy the application and return to the All Applications table.

Proposed Business Applications: When you have deployed all your Common Services, the deployment wizard will present you with the first proposed business application for your review. At this point you can choose to continue with the deployment wizard and go through the automated list of proposals. You can also close the Application Details page and, from the Applications table or topology, select the proposed business application you want to review and deploy next.

Business Application Names: If you were able to provide application naming convention data, Policy Generation will have named the Business Applications for you. If not, Policy Generation will create a unique name based on the longest common prefix among all the workloads of the application. Be sure to examine the tier workloads or subnets and the ACL rules to confirm or edit the application name. You can select any tier rectangle or connection line to view the details of each as you determine which application you are looking at. By default, FortiPolicy shows only the connections for the selected tier and hides all the other connections. To show all the connections at once, select the Toggle Connections icon under Views.

Divide Combined Proposals: If you have business applications that communicate with each other, Policy Generation might not be able to accurately separate them into unique proposals. If you find that a proposal contains the tiers of two or more applications, then select the Assign Tiers icon under Actions and assign tiers to different applications, thus dividing the proposal into two or more proposals. Then approve and deploy each of the new proposals. See the Assign Tiers section below for more details.

Name the Deployment Environment: Confirm or edit the proposed environment. Usually, you do not want to leave business applications in the Default environment. You will need to determine what deployment environment each application belongs in. Sort them into Production, Development, Test, and so on.

Name the Tier Function: Confirm or edit the proposed tier function. Policy Generation will propose the tier function, based on the application components, ports, and protocols used by the tier: Web, Business Logic, Database, Other, Service, or External. Examine the workloads in the tier to confirm the function of the tier. To select a different tier function, pick from the dropdown list in the Tier Members Table header. In some cases, you might have more than one tier with the same tier function in an application. The system will automatically add a digit to the end of the tier function to be sure that each tier is uniquely identified.

Name the Tier: Each tier rectangle in the map displays the tier name. By default, workload tier names are a concatenation of the Tier Function tag, the Deployment Environment tag, and the Application Name tag. As you edit any of these individual values, those edits are automatically applied to the workload tier names. Subnet tier names are a concatenation of the tier function and the first subnet. The tier names are shown as sources and destinations in proposed ACL rules. This makes it easy to read the rules and understand what is allowed to talk to what. Tier names are also displayed on the Tier Members Table header bar together with an edit icon. If you want to give a different name to some tiers, select the edit icon.

If you manually edit a tier’s name, the system keeps that name and ceases its auto-naming behavior if you later change the application name, environment, and/or function.

Describe the Tier: On the far right of the Tier Members Table, you can select the Add Description link if you want to add notes about the tier. Such notes can be helpful when you are first trying to identify which of your applications is being proposed. Your notes might also be helpful when reading the rules in the Policy > Access Control table.

Review the Workload Tiers: Confirm, Add, or Delete workloads. Now you can review the proposed workloads in the tier. Confirm that they all have the same function and have the same security policy requirements. By definition, a tier is a set of members that all share an identical set of security requirements. If necessary, you can remove any workloads that do not belong in the tier by selecting the Delete icon. To add any workloads that should be in the group but are not, find the workloads you want and delete them from their current tiers. Then select the Add icon at the upper right in the table header and select the workloads you want to add.

Review the Subnet Tiers: Confirm, Add, Edit, or Delete subnets. Now you can review the proposed subnets in the tier. Confirm that they all have the same function and have the same security policy requirements. If necessary, you can remove any subnets that do not belong in the tier by selecting the Delete icon. To edit a subnet, select the edit icon button. Select Add Subnet as needed to add subnets.

Approve the Application, Deployment Environment, and Tier Functions: To keep track of which tiers you have reviewed and approved, when you agree with the workloads or subnets in the tier and the tier function, click Approve Tier. The approved tier’s status icon will change from a yellow exclamation to a black and white check mark. The deployment wizard will automatically advance to select the next tier in the application. Repeat the approval steps for each tier. When all tiers are approved, they will all be marked with a black and white check mark, and the deployment wizard takes you to the first connection that needs to be approved.

Approve Connection ACL Rules: Confirm or edit the ACL rules that make up the first connection. ACLs can only be confirmed after the tiers on both ends of the connection are approved. You will see that a connection and the tiers on both sides are selected in pink. Review the tiers’ ACL rules in the table below the application map graphic. Either confirm or edit them so that they allow the traffic you want to permit between the two tiers. You can delete a connection by deleting all its ACL rules.

Add Connections: In the rare case that a connection between tiers of an application is missing, you can add a connection. On the application map, select the two tiers that you want to connect (Select tier one, press the Shift key, and select tier two). Then select the Add Connection icon under Actions. The system will draw a new connection between the two tiers and present you with an ACL rule that you can edit.

Merge Tiers: If Policy Generation has proposed two separate tiers but you think of them as one tier with the same security requirements, then you can select two tiers of the same type, workload, or subnet: Select tier one, press the Shift key, and select tier 2. Then select the Merge Tiers icon under Actions. The two tiers are merged into one and share a combined set of ACL rules. Now review and approve the new tier.

Delete Tiers: If you find that a tier does not belong in a proposal, you can use the Assign Tiers feature, mentioned above, and described in more detail below, to assign it to another proposal, or you can delete that tier by selecting the tier and then selecting the Delete Tier icon under Actions. Deleting a workload tier will temporarily free up its workloads, allowing them to be added to other tiers. In the next discovery cycle, Policy Generation will propose application tiers for any freed workloads or subnets.

Common Services Object: All common network services that support the functions of the tiers in the business application are grouped into a single Common Services object, displayed in the far-right column of the application map, under the header External. These are service applications that are external to the business application, but necessary for its participation in the network. In the preferred workflow, these common services will already be deployed when you are reviewing your business applications. The approval process will not automatically review these service applications. You may select the Common Services object to see a list of the service applications that support this business application.

External Tiers: In the first and sixth columns of the six-column application map, you might see External Tiers. These are tiers that seem to connect to the proposed business application from the Internet or from other applications. The Any IP Address tier at the top left is a Subnet tier, representing any workload or IP address that is outside the network that Policy Generation examined and might represent the Internet or addresses not identified as part of a proposed application. The Tier Member Table displays the actual IP addresses that have been detected. Determine what external object exists at these IP addresses and then note the address and description of that object in the tier’s Description field. You can leave the broad tier definition of all IP addresses, 0.0.0.0/0, or, for each application, you can edit this subnet to fit the address ranges you want to allow.

Any other external tiers in the first column are members of other proposed applications that are sources, only connecting to web tiers of the current proposed application. In the sixth column, below the Common Services object, you might see external tiers from other proposed applications that are sources and/or destinations that connect to other tiers in the current proposed application. To deploy the current application with all its proposed ACL rules, these external tiers must also be reviewed, approved, and deployed.

Approve ACL Rules: After all the internal and external tiers are approved, the wizard will display the first connection with the first tier. Review and edit each tier’s ACL rules. When you agree with all the rules on a single connection, click Approve Policy. That connection will change from a thin yellow line to a thicker black or white line. The deployment wizard will automatically advance to the next connection in the application. Repeat the above approval steps for each connection.

Approval Complete: When all application tiers and connections are approved, you will see the Approval Complete message, giving you the choice to deploy the application now or later. If you are ready to deploy now without anyone else’s review, then click DEPLOY RULES NOW. Deploying the proposal will prevent further editing of the proposal and will send the rules to the FortiGate, or the alternate policy table if so configured. The rules will be deployed to the specific FortiGate on which the tier workloads were found. The deployed rules can be seen in FortiGate under Policy and Objects. All FortiPolicy-created artifacts can be identified from the comment “FortiPolicy created.”

If you are still using the deployment wizard, the next proposed business application will appear, or you can select the next business application you want to approve and deploy from the Applications table or topology.

Editing Deployed ACL Rules: In FortiPolicy all deployed rules can be viewed in the Policy > Access Control page. New ACL rules can be added, and deployed ACL rules cab be deleted. Although it may appear like you can edit them, you cannot directly edit deployed policy ACL rules in the Policy > Access Control table. There is this workaround:

1. Duplicate the rule you want to change.

2. Edit the duplicate.

3. Delete the original rule.

4. Select the SAVE button.

The original rule will be deleted from, and the new rule will be added to, all the right VDOMs

Editing Deployed Tiers: The easiest way to edit deployed applications, is to delete the application by clicking the Delete item on the application’s action menu. This will remove all the ACLs and tiers, freeing up all the workload and subnet members of the application. Policy Generation will discover all the connections and propose the application again. Wait till all the connections have been discovered. Then go through the application approval process again. While approving tiers and ACLs, it is relatively easy to edit the proposals, editing, adding, or subtracting workloads, subnets, and ACL rules as you like. Once edited, deploy the application again.

However, you may want to edit the membership of one tier while the application remains deployed and secure.

To edit subnet tier members, copy the tier name from the Applications table or from the Application Details page. On the Groupings page, search for the tier name. From the tier’s action menu on the right side of the table row, click Edit. On the resulting Edit Resource Group page, you can now add, remove, or edits the subnets and then click SAVE. The system will automatically deploy the changes tier definitions to the right VDOMs.

Quick Deployment: Although it is NOT best security practice, for demonstration purposes, you can skip the careful review and approval of each proposed detail and deploy a proposal quickly by selecting the small dropdown arrow in the bottom right corner of the Application Details page and then clicking DEPLOY RULES.

Assign tiers

In some cases, Policy Generation may group two or more separate applications together, if they talk to each other. The Assign Tiers panel lets you divide such a proposal into separate application proposals.

In other cases, Policy Generation may propose two applications, but you think of them as being one bigger application. The Assign Tiers panel lets you merge them together.

Divide Proposal Example:

Your Scheduling and Inventory applications each have their own web servers and business logic servers, but they share the same database, and both are connected to the Internet.

The logic severs in Scheduling need to talk with the logic severs in Inventory. They operate together in your Production environment, but you manage them as separate applications.

To identify and control traffic for each application, as well as the traffic between applications, you want to group the servers into tiers and name the tiers and their applications appropriately.

Take the following actions:

1. Examine the tiers in the proposed Application Details page and determine that the tiers belong to more than one application.

2. On the toolbar, under Actions, click the Assign Tiers icon button to display the Assign Tiers panel.

3. If the New Proposal panel is not open, click . Enter the Application Name and Environment, Inventory / Production, and click SAVE.

4. Click the Inventory Web tier, a workload tier.

5. In the tier table header, Assigned Proposal dropdown, click Inventory / Production. The tier moves into the new Inventory / Production proposal.

6. Subnet tiers, like Any IP Address, are children of the workload tiers they connect to. They move where their parent moves. A copy of Any IP Address moves to the new proposal.

7. Click the Inventory Logic tier, another workload tier. In the Assigned Proposal dropdown, again click Inventory / Production. The logic tier moves to the new proposal.

8. Workload tiers only belong to one application, but they may talk to tiers in other applications.

9. The database workload tier can be left in Scheduling, moved to Inventory, or click again to assign it to an application all by itself.

10. Click SAVE at the bottom of the panel. Policy Generation will divide the original proposal into two applications with the appropriate interapplication connections.

11. Now approve and deploy the two applications separately.

Merge Proposals Example:

Your Sales Accounting and Revenue Recognition applications are managed by the same team and work closely together. You think of them as one big application, even though they run on different sets of servers. Based on its initial setup and discovered data, Policy Generation proposed them as two separate applications.

You want to group all the tiers together in one application and manage their security as one application.

Take the following actions:

1. From the Applications table or topology, click the proposal with the smallest number of tiers: Revenue Recognition.

2. In its resulting Application Details page, on the toolbar under Actions, click the Assign Tiers icon button to display the Assign Tiers panel.

3. The other application that you want to merge may already appear in the panel. If not, and if the New Proposal panel is not open already, click ADD APPLICATION.

4. Enter the Application Name and Environment, Sales Accounting / Production, and click SAVE.

5. Click a workload tier in Revenue Recognition.

6. In the tier table header, Assigned Proposal dropdown, click Sales Accounting / Production. The workload tier and any child subnet tiers will move into Sales Accounting / Production.

7. Repeat steps 5 and 6 until all the tiers are moved into Sales Accounting / Production.

8. Click SAVE at the bottom of the panel. Policy Generation will merge all the tiers into one application proposal.

9. Now approve and deploy Sales Accounting / Production as one application.

Policy Generation advanced settings

With the guidance of Fortinet support, you can change some default settings. Go to Workspace > Applications > Edit Setup ( or Setup Policy Generation) > Scope. Select the Advanced Settings link in the upper right corner of the page. The Advanced Settings dialog appears.

• Discover Connections

• Discovery Cycle Duration

• Grouping Rules

• Similarity Index

• Data File

• Deployed Applications

• Reset

Discover Connections

This is set to RUN when you finish the Setup Policy Generation wizard. If you anticipate network disruptions or you want to stop Policy Generation from learning for a period, you can manually stop discovery. To manually stop connection discovery:

1. Click the checkbox to set it to STOP.

2. Click CLOSE on the Policy Generation Advanced Settings dialog.

3. Click the SAVE and CLOSE buttons on the setup wizard.

4. To manually RUN again, repeat these same three steps, setting Discover Connections to RUN.

Discovery Cycle Duration

The default duration of each discovery cycle is two hours. Policy Generation needs this time to listen to all the workload-to-workload connections. It then takes additional time to learn by analyzing the data and makes its proposals. Typically, you should let Policy Generation run through many two-hour cycles, until it is no longer discovering many new unique connections. However, sometimes for demonstration purposes, an advanced user might shorten the discovery cycle down to its shortest duration of 15 minutes.

Grouping Rules

Most users will benefit from the default grouping rules setting, which groups by function and by connections. In this way, the system can distinguish between the different types of tiers and the different applications. Some users only want to group certain types of assets, for example, grouping all databases. To group your workloads into functional groups, uncheck the default checkbox: Also group by the connections that each workload makes.

Similarity Index

The 91% default similarity setting has worked well for most users.

If you find that this setting creates groups that include many workloads that should not be included, uncheck the checkbox and set the similarity setting a little higher.

If you find that this setting creates groups that do not include all the workloads they should, uncheck the checkbox and set the similarity setting a little lower.

If you do not make any edits while connection discovery is happening, then you can make these adjustments afterward, and the proposals will be recomputed at the end of the next discovery cycle.

If you have started to approve and deploy applications but you are not happy with the results, you can DELETE ALL deployed applications.You can delete individual deployed applications that you are not happy with from the Applications table. Then adjust the similarity index. The next data analysis will continue at the new similarity setting.

The above Advanced Settings actions on the left side of the panel will take effect upon selecting CLOSE and then selecting Next or SAVE.

Data File

The EXPORT JSON button will download a file of all the connections and proposal data that Policy Generation has accumulated. Fortinet support might request this data to help you.

Deployed Applications

The DELETE ALL button will remove all the applications that were deployed to the FortiGate using Policy Generation in case you want to start over again. This action will take effect upon selecting the YES button on the confirmation dialog.

Reset

The PURGE DATA button will leave any deployed applications in place but will delete existing connection data and proposals and will set connection discovery to RUN. This action will take effect upon selecting the YES button on the confirmation dialog.

What to do next

Refer to the following FortiPolicy documentation for more information about the current release:

• Fortinet FortiPolicy 7.2.0 Product Release Notes

• Fortinet FortiPolicy 7.2.0 Quick Start Guide for VMware