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.