Applications

The Applications page contains the following:

• Actions Steps panel for automated policy generation

  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 Security Fabric. See Automated policy generation.

• Tabs

  The tabs are for All Applications, Common Services, Default, and the deployment environments that you specify in the Policy Generation wizard. The default deployment environments are Production, Development, Test, Staging, and PCI. Click on a tab to select which applications or services to display. Each tab has two views:

  • Applications table
  • Applications Topology Map

  

  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.

• Insertion Staging link

  Insertion staging is described in Insertion staging.

• Buttons

  • Applications Table button

    Click Applications Table to see applications in a tabular format.

  • Applications Topology Map button

    Click Applications Topology Map to see applications in a graphical format.

  • Refresh button

    Click Refresh to view the most recent results.

  • Toggle Connections/Hide All Connections button

    When you are in the Application Topology Map, click Toggle Connections/Hide All Connections to show or hide the connections between applications.

  • Show All Applications/Hide Applications button

    When you are in the Applications Topology Map, click Show All Applications to see all applications. Click Hide Applications to see only applications that are connected to the currently selected application.

• Applications in tabular or graphical format

  • Applications tables

    The Applications tables display details of all the proposed, approved, and deployed 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 device, 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. Clicking the vertical ellipsis on the far left of each table row displays the actions that can be taken on each application, based on its deployment status.

  • Applications Topology Map

    The Applications Topology Map lets you easily see which applications are connected to other applications. Click the Applications Topology Map icon in the upper right corner of the Applications page for the Applications Topology Map. Select a connection between two applications to view the proposed ACL rules that connect them.

    

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

  Click on the application name in the Applications table or Tier Count links in the Applications Topology Map to display the Applications Details page with details on each tier and connection in the application. See Applications Details page.

  When you first visit the Applications page, no applications are shown. Complete Step 1: Discover connections to discover and display available applications.

Automated policy generation

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.

Policy Generation uses machine learning to do the following:

• Discover all connections between your workloads and identify the functions of all the workloads and their interconnections.

• Group discovered workloads into proposed applications and application tiers and propose tags for the workloads:

  • Tier functions

  • Deployment environments

  • Application names

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

• Propose access control list (ACL) rules that permit observed traffic between tiers.

• Help you to systematically review, edit, approve, and deploy each proposal.

• Help you to microsegment or segment workloads in preparation for enforcing policy rules.

• Test the deployment on actual traffic for a second review and edit.

• Add a security tag to the application workloads to enforce policy and permit only traffic allowed by your ACL rules.

The following are required for automated Policy Generation:

• FortiPolicy installation

  See Installing FortiPolicy.

• FortiPolicy license

  See Importing the FortiPolicy license file.

• Security Fabric

  Add a fabric connector to the root FortiGate device of your Security Fabric and authorize the connection between FortiPolicy and the FortiGate device. See Creating a fabric connector.

• Layer-7 data

  From the root FortiGate device, enable layer-7 discovery on existing ACL rules that are providing flow data .FortiPolicy displays the fabric workloads on the Workspace > Assets Map page 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

  Create a data plane for each FortiGate device with connected workloads that you want to secure. See Configuring data planes.

There are five Policy Generation steps in the Action Steps panel to process raw, unsecured workloads into applications in a fully microsegmented Security Fabric:

• Step 1: Discover connections

• Step 2: Deploy applications

• Step 3: Microsegment

• Step 4: Test policy rules

• Step 5: Secure

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

Step 1: Discover connections

Click SETUP POLICY GENERATION in the Action Steps panel on the right side of the Workspace > Applications page 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. See Connection discovery.

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 the following:

• Scope tab

  Specify where to look for connections and how to process the data.

• Public IPs tab

  Enter public IP addresses that are to be analyzed as part of your internal private network scope.

• Filters tab

  Add logical rules to limit the scope specified in the Scope and Public IPs tabs.

• Names tab

  Specify your workload naming convention, so the system can name applications, tiers, and deployment environments for you.

• Tags tab

  Specify how to name applications, application tiers, and deployment environments and how to tag workloads.

• Services tab

  Check the names of common network service applications that support networks and the ports and protocols they use. Identifying network services is crucial to deriving the optimal set of business applications.

Scope tab

In this tab, 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.

1. In the Security Policy Set dropdown list, keep the default setting of Discover for automated policy generation.

2. In the Access Control Policy dropdown list, select the policy table in which you want to store the ACL rules. Select one of the following:

   • The same ACL policy you assigned to the Security Fabric. Usually this is the Default ACL Policy.

     The name of the Security Fabric is displayed to the right of the Access Control Policy dropdown list. When you deploy an application, its ACL rules are copied to the selected policy and immediately deployed to the root FortiGate device and its appropriate Security Fabric VDOMs.

   • A different ACL policy from the one you assigned to the Security Fabric.

     To create an ACL policy, see Access control. If the ACL policy is not tied to the Security Fabric, no fabric name is displayed to the right of the Access Control Policy dropdown list. You can deploy ACL rules to the new ACL policy, but those rules will NOT be forwarded to the Security Fabric until you associate the new ACL policy with the Security Fabric on the Configurations > Security Fabric page.

3. Under Security Fabric Name, select the checkbox for the Fortinet Security Fabric. This allows Policy Generation to gather data from the Security Fabric.

4. If Fortinet Support asks you to change the default settings, click Advanced Settings.

   See Advanced settings.

5. Click NEXT.

Public IPs tab

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, 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, Policy Generation will propose a generic, all-inclusive tier with the universal IP range of 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 you are finished, click NEXT.

Filters tab

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

Add include filters to specify which of the defined workloads and subnets to examine. Include filters narrow the scope.

Add exclude filters to specify which of the defined or included workloads and subnets already specified should NOT be examined. Exclude filters also narrow the scope.

When you are finished, click NEXT.

Names tab

Policy Generation proposes names for application workload tiers based on the following:

• Application name, such as CRM or Accounting

• Deployment environment, such as Production, Development, or Testing

• Tier function, such as Web, Database, or Application Logic

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

• Delimiter-based: This common naming convention format allows codes of different lengths for each value by inserting a delimiter like _ underscore or . period between code sections.

• Positional: This common naming convention format allows codes of a set length for each of its values.

FortiGate devices do not currently support a native tagging system.

If your workload names do not provide any of these three data values in a pattern that Policy Generation can read, then select None of these fit my configuration.

When finished, click NEXT.

Tags tab

Policy Generation uses its own key/value tags to identify the workloads as members of the following:

• Applications

• Tiers

• Deployment environments

There are three sub-tabs, one for each of these three categories of data.

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 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. 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 names. If all your users are comfortable using the strings in your naming convention, you do not need to change anything.

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.

When you are finished, click NEXT.

Services tab

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 tab presents a list of many of the most common network 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.

Updating the information on this tab allows Policy Generation to better distinguish between the following:

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

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

When you have completed the six tabs in the Setup Policy Generation wizard, click DONE to submit your input, close the wizard, and return to the Applications page, where you will see that connection discovery has started.

Connection discovery

When you click DONE in the Setup Policy Generation wizard, connection discovery begins. Step 1: Discover Connections shows the time and date connection discovery started. A status message displays the time when the first discovery cycle will complete, but it might take longer for the first data point to appear on the chart.

Connection data is displayed in the New Connections graph in Step 1 after each 2-hour discovery cycle, plus computation time. Even after just the initial discovery cycle, Policy Generation will begin proposing applications and policies.

Do not approve or deploy applications at this point. Let Policy Generation 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 stabilizes at 0, you can move to Step 2: Deploy Applications.

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

Step 2: Deploy applications

In Action Step 2: Deploy Applications, click START.

The deployment wizard displays the Application Details page and walks you through the deployment of the following:

• Common network 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 device’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. 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.

  • Make your own choices.

    To decide for yourself which business applications you want to secure first, close 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.

Common network services

For common network services, you can make the following changes:

• Edit the name of the service tier.

  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 might want to edit them in ways that conform to your liking and needs. You can edit the name of the service tier as needed.

• Select the deployment environment.

  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, such as 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.

• View the function.

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

• Approve the tier members.

  A tier can 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 might 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 Approve Tier 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 the 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 Approve Policy in the lower right corner.

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.

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 can 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 Applications page.

Business applications

For business applications, you can do the following:

• Choose an application to secure.

  Search and sort the application table or search and scan the Application Topology Map 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 application table or click the tier count link in the Application Topology Map to open the Application Details page.

• Approve and 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 device and its Security Fabric.

• Approve and 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 and deploy to an alternate ACL table.

  There is an 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.

For business applications, you can make the following changes:

• Edit the name of the business application.

  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.

• Select 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.

• Review 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.

• Edit the tier name.

  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.

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

• Add a description.

  On the far right of the Tier Members Table, you can click Add Description 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 proposed workloads.

  Confirm, add, or delete the proposed workloads. 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 proposed subnets.

  Confirm, add, edit, or delete 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. Click Add Subnet as needed to add subnets.

• Approve the tier.

  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 the 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 one tier, press the Shift key, and select the second tier). 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 merge two tiers of the same type, workload, or subnet. Select one tier, press the Shift key, and select the second tier. 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 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.

• Review the 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.

• Review 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.

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 device or the alternate policy table if so configured. The rules will be deployed to the specific FortiGate device on which the tier workloads were found. The deployed rules can be seen in FortiOS 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.

If necessary, you can change deployed ACL rules and deployed tiers:

• 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. Click SAVE.

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

• The easiest way to edit deployed applications is to delete the application by selecting Delete from 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 until 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. After editing the application, deploy it again.

  However, you might 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.

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.

Step 3: Microsegment

Insertion is the process of configuring the Security Fabric to monitor and regulate an application’s traffic. It requires that the ACL rules are deployed to the Security Fabric. Insertion is a prerequisite for the next two action steps (Step 4: Test Policy Rules and Step 5: Secure).

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

• Microsegment

  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 device. When later enforced, the rules that you have deployed will govern what workloads can talk to each other and what traffic will be blocked. Microsegmentation is more secure than segmentation, but your system's performance will be slower because more traffic is being examined.

  To microsegment a workload, go to Workspace > Applications, click the vertical ellipsis at the left end of an application row, and select Microsegment. If you click INSERT in Step 3 of the Action Steps panel, all deployed business applications and common services applications that have not been segmented are microsegmented.

• Segment

  Segmentation puts a firewall around every application tier. When the security policies are enforced on the FortiGate device, the FortiGate device monitors and controls all traffic between tiers. Traffic within tiers is not controlled by the FortiGate device. Segmentation is less secure than microsegmentation, but your system will perform better. To segment an application tier, go to Workspace > Applications, click the vertical ellipsis at the left end of an application row, and select Segment.

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

Insertion staging

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 a 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 the Insertion Staging link. The Insertion Staging queue is located at Workspace > Grouping > Insertion Staging.

Applications placed into Insertion Staging are queued to be segmented or microsegmented, whichever you chose.

To be selective, click COMMIT ALL CHANGES on the Insertion Staging page. This executes all the segmentations and microsegmentations that you specified. Deployed applications that have not been queued are not segmented or microsegmented.

To microsegment in bulk, click INSERT at Action Step 3: Microsegment. This will do the following:

• Segment or microsegment all applications sitting in the Insertion Staging queue, if any.

• Microsegment all deployed applications that are not inserted and not in the Insertion Staging queue.

The Insertion Progress bar in Step 3: Microsegment 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.

Step 4: Test policy rules

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:

• Acknowledged 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.

• Acknowledged as legitimate

  This is valid traffic that either was not detected during connection discovering at Step 1: Discover Connections 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.

You can test all deployed and inserted applications in bulk or be selective about which applications to test when.

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

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

• Summarized into unique violation types every hour

• Displayed in the Unresolved Violations chart every 5 minutes

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: Secure.

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 display 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. Click 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 Acknowledged 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 click SAVE.

When all the violations are resolved and new ones are no longer appearing, you can click 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 Test ACL Rules from the action menu for each application to test.

Step 5: Secure

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:

1. In the Applications table or topology, click the application’s action menu.

2. Click Enforce ACL Rules.

   That application is now secure.

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

To enforce all ACL rules for all deployed and inserted applications:

1. Click ENFORCE POLICY at Action Step 5: Secure.

   All your applications are now secure.

2. If at any time you want to stop enforcing all applications’ ACL rules, click Revert at Action Step 5: Secure.

Advanced settings

The following advanced settings are available:

• By default, the Run checkbox is selected.

  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. Clear the RUN checkbox.

  2. Click YES in the Turn Off Application Discovery dialog.

  3. Click CLOSE in the Advanced Settings dialog.

  4. Click SAVE and CLOSE in the Policy Generation wizard.

• By default, the Every 2 hours - Default checkbox is selected.

  Policy Generation needs this time to listen to all the workload-to-workload connections. Then it learns from 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. If you want a shorter discovery period, clear the Every 2 hours - Default checkbox and move the slider.

• By default, the Also group by the connections that each workload makes. - Default checkbox is selected.

  The default setting groups workloads 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, such as databases. To group your workloads into functional groups, clear the Also group by the connections that each workload makes – Default checkbox.

• By default, the 91% - Default checkbox is selected.

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

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

  You can make these adjustments during or after connection discovery. Proposals are recomputed at the end of the next discovery cycle.

  If you have started to verify and implement applications and decide that you need to change this setting, you can click DELETE ALL. 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.

• Click EXPORT JSON to download a file of all the connections and proposal data that Policy Generation has accumulated. Fortinet Technical Support might request this information for troubleshooting.

• Click DELETE ALL to remove all the applications that were deployed to the FortiGate device using Policy Generation in case you want to start over again. This action will take effect after you click YES in the confirmation dialog.

• Click PURGE DATA to delete existing connection data, proposed applications, and policy rules. Deployed applications are not affected. The RUN checkbox will be selected. This action will take effect after you click YES in the confirmation dialog.

Applications Details page

To open the Applications Details page, go to Workspace > Applications and do one of the following actions:

• Click on the application name in the Applications table.

  

• Click Tiers in the Application Topology Map.

  

The Applications Details page has four main sections:

• Header bar

  The header bar has the application name, environment, risk score, status, Views buttons, Actions buttons, number and percentage of approved tiers, number and percentage of approved policy rules.

• Map view

  By default, the Map view is shown when you open the Applications Detail page. The Map view shows the proposed tiers and connections.

• Members table

  The members table lists the workloads, subnets, or ACL rules of the object selected in the Map view.

• ACLs view

  Click ACLs in the header bar to switch from Map View to ACLs view. The ACLs view lists the proposed ACL rules for the application.

The Actions buttons allow you to do the following:

• 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 a proposal contains the tiers of two or more applications, then select the Assign Tiers icon in the Actions buttons area and assign the tiers to different applications, thus dividing the proposal into two or more proposals. Then approve and deploy each of the new proposals.

• Merge proposals

• Add a connection between selected tiers

  If a connection between tiers of an application is missing, you can add a connection. On the application map, select a tier, then press the Shift key and select another tier. Then click the Add a Connection icon in the Actions buttons area. FortiPolicy draws a new connection between the two tiers and presents you with an ACL rule that you can edit.

• Merge two selected tiers of the same member type

  If Policy Generation has proposed two separate tiers but you want them to be one tier with the same security requirements, then you can select two tiers of the same type, workload, or subnet. Select one tier, press the Shift key, and select another tier. Then select the Merge Two Selected Tiers icon in the Actions buttons area. The two tiers are merged into one and share a combined set of ACL rules. Now review and approve the new tier.

• Delete selected tier

  If a tier does not belong in a proposal, you can use the Assign Tiers feature described above to assign it to another proposal. Or you can delete that tier by selecting the tier and then selecting the Delete Tier icon in the Actions buttons area. 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.