Zero_Trust_Access_7.2_Study_Guide-Online.pdf

DO NOT REPRINT © FORTINET Zero Trust Access Study Guide for FortiOS 7.2 DO NOT REPRINT © FORTINET Fortinet Training Institute - Library https://training.fortinet.com Fortinet Product Documentation https://docs.fortinet.com...

DO NOT REPRINT © FORTINET Zero Trust Access Study Guide for FortiOS 7.2 DO NOT REPRINT © FORTINET Fortinet Training Institute - Library https://training.fortinet.com Fortinet Product Documentation https://docs.fortinet.com Fortinet Knowledge Base https://kb.fortinet.com Fortinet Fuse User Community https://fusecommunity.fortinet.com/home Fortinet Forums https://forum.fortinet.com Fortinet Product Support https://support.fortinet.com FortiGuard Labs https://www.fortiguard.com Fortinet Training Program Information https://www.fortinet.com/nse-training Fortinet | Pearson VUE https://home.pearsonvue.com/fortinet Fortinet Training Institute Helpdesk (training questions, comments, feedback) https://helpdesk.training.fortinet.com/support/home 3/10/2023 DO NOT REPRINT © FORTINET TABLE OF CONTENTS 01 ZTA Overview 4 02 ZTA Components 30 03 Securing Network Access with FortiNAC 69 04 Configure ZTNA for Secure Application Access 100 05 Expanding Secure Access With Endpoint Posture and Compliance Checks 133 06 Monitoring ZTA Enforcement and Responding to Incidents 163  ZTA Overview DO NOT REPRINT © FORTINET In this lesson, you will learn about zero trust access (ZTA) design principles for network, user, and application security. Zero Trust Access 7.2 Study Guide 4  ZTA Overview DO NOT REPRINT © FORTINET After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating competence in ZTA security design principles, you will be able to describe the issues associated with legacy security design and how ZTA can help address modern problems with user, application, and network security. You will also be able to describe the fundamental technologies required to enable ZTA to be used in an environment. Finally, you will understand the differences between zero trust network access (ZTNA) and ZTA. Zero Trust Access 7.2 Study Guide 5  ZTA Overview DO NOT REPRINT © FORTINET In this section, you will learn about legacy perimeter-based security architecture. Zero Trust Access 7.2 Study Guide 6  ZTA Overview DO NOT REPRINT © FORTINET Perimeter-based architecture was the traditional approach to network security. In this architecture, the entire network is on premises, for example—corporate data centers. The primary idea behind perimeter-based architecture was to trust devices inside the network and not to trust devices outside the network. Once inside the network, implicit trust is granted, and the user has access to all the corporate resources. The network perimeter is protected by components like firewalls, intrusion detection system (IDS), demilitarized zone (DMZ), and so on. External users and devices are provided remote access to the network using virtual private network (VPN). Over the past decade, many flaws related to network security have been identified in this architecture model. Zero Trust Access 7.2 Study Guide 7  ZTA Overview DO NOT REPRINT © FORTINET This slide shows an analogy of how networks were deployed in the earlier days and how perimeter-based security architecture can be easily implemented. Once inside the network, implicit trust is granted to the device and user. Zero Trust Access 7.2 Study Guide 8  ZTA Overview DO NOT REPRINT © FORTINET This slide shows an analogy of how networks are currently deployed. With the increase in the number of BYOD, IoT devices, and remote users working from home and remote offices, the perimeter-based architecture is deficient in meeting network security requirements. Zero Trust Access 7.2 Study Guide 9  ZTA Overview DO NOT REPRINT © FORTINET With BYOD and IoT devices increasing rapidly in today’s world, it becomes essential that we have visibility of these devices. Network visibility is required to monitor devices with vulnerable software, increased malware infiltration, and so on. The real challenge is headless devices where an endpoint protection platform (EPP) cannot be installed. Zero Trust Access 7.2 Study Guide 10  ZTA Overview DO NOT REPRINT © FORTINET The main challenge with legacy security architecture is moving away from the traditional on-premises data center and moving toward private and public clouds. With more employees working remotely, allowing BYOD and adding IoT devices to your network increases the complexity of monitoring all these devices. VPNs can provide access to the corporate network from the public internet, but there is no visibility of what data is extracted and what malware is propagated from the compromised remote endpoints or user accounts. Zero Trust Access 7.2 Study Guide 11  ZTA Overview DO NOT REPRINT © FORTINET In this section, you will learn about ZTA and review ZTA use cases. Zero Trust Access 7.2 Study Guide 12  ZTA Overview DO NOT REPRINT © FORTINET According to Forrester, zero trust abolishes the idea of a trusted network inside a defined corporate perimeter. ZTA mandates that enterprises create microperimeters of control around their sensitive data assets to gain visibility into how they use data across their ecosystem to win, serve, and retain customers. ZTA is a security strategy that has three core principles: 1. Never trust and always verify: This is not only where first-time authentication happens, but continual verification authentication for every session. For example—is the user still authenticated, does the user still have valid credentials, does the user have the proper access permissions, and so on? 2. Minimal access: Provide users with only the required privileges to perform their jobs. This is where micromsegmentation and macrosegmentation can be deployed to control traffic flow within the network. 3. Assume breach: This is where the zero-trust principle applies. Implement security solutions and policies pretending you have been already compromised and what security measures can be taken, if compromised. Zero Trust Access 7.2 Study Guide 13  ZTA Overview DO NOT REPRINT © FORTINET ZTA is a strategy to provide end-to-end zero trust to users, devices, and applications when they access components on the network. Zero trust requires knowing everyone and everything on the network, and controlling who and what has access to resources on the network. Zero Trust Access 7.2 Study Guide 14  ZTA Overview DO NOT REPRINT © FORTINET Forrester has defined seven pillars in their ZTX framework. The first pillar represents how to secure data. Firstly, you need to know what kind of data your organization has, so that it can be categorized and classified accordingly. Then, you must decide what levels of protection and encryption are required for the data at rest and in transit. Finally, you must provide access to data on a need-only basis. Zero Trust Access 7.2 Study Guide 15  ZTA Overview DO NOT REPRINT © FORTINET The second pillar defines how to secure users. This is where user authentication happens and where users are assigned access permissions for the data. After the initial user authentication, you should continuously monitor user validation and permissions to prevent unauthorized access to data. This type of monitoring was lacking in the traditional security architecture. Finally, use multifactor authentication (MFA) in your organization to secure user access. This should be the normal practice in today's cybersecurity world. Zero Trust Access 7.2 Study Guide 16  ZTA Overview DO NOT REPRINT © FORTINET The third pillar defines how to secure the networks. This is where your corporate assets are segmented into subnets, VLANs, and so on. All categorized and classified data must reside in its segment with its associated access levels. Microsegmentation must be applied to endpoints and applications within the same segment to control and monitor user activity. Zero Trust Access 7.2 Study Guide 17  ZTA Overview DO NOT REPRINT © FORTINET Workloads are front-end and back-end systems that run business and help them to win, serve, and retain customers. Just like any other area of zero trust, these connections, applications, and components must be treated as threat vectors and be protected using zero-trust controls, such as policy-based API inspection and control, container-file and active-memory protection, and guest-host firewalls. Of particular concern are workloads running in public clouds. Zero Trust Access 7.2 Study Guide 18  ZTA Overview DO NOT REPRINT © FORTINET The fifth, and most important pillar, defines how to secure devices. This is where you gain visibility of managed and headless devices. Detect and mitigate any spoofing attacks and suspicious behavior of these devices. Finally, you should implement and continuously monitor device security posture to ensure the devices onboarded to the network are safe. For example, does the endpoint have the latest antivirus signatures, operating system updates, and so on? Zero Trust Access 7.2 Study Guide 19  ZTA Overview DO NOT REPRINT © FORTINET The last two defined pillars are automation and orchestration, and visibility and analytics. Organizations and security leaders need to use tools and technologies that enable security automation and orchestration (SAO) across their enterprises to shorten incident response times and integrate disparate security solutions. Orchestration extends security policies to cloud environments. The security analyst needs to have the ability to accurately observe threats that are present and orient defenses more intelligently. Zero Trust Access 7.2 Study Guide 20  ZTA Overview DO NOT REPRINT © FORTINET Fortinet takes a platform approach to cybersecurity. It uses a whole ecosystem of security products to secure the network. Within the Fortinet Security Fabric, there are several pillars, and ZTA is one of those pillars. ZTA focuses on how to onboard users and devices and enable them to access resources on the network. Fortinet Security Fabric provides the broad, integrated, and automated capabilities you need for cybersecurity. Zero Trust Access 7.2 Study Guide 21  ZTA Overview DO NOT REPRINT © FORTINET Knowing who is on the network is the most common and accessible area of zero trust. From an identity management perspective, you need to know who the user is and how you will authenticate them. Are you going to be using password-only or multifactor authentication? Multifactor authentication aids a zero-trust network by increasing the number of user-specific credentials required for access. As part of zero-trust principles, role-based access can provide the minimum access necessary to perform the user's jobs. Zero Trust Access 7.2 Study Guide 22  ZTA Overview DO NOT REPRINT © FORTINET Knowing what is on the network is the most challenging area of zero trust. Organizations must discover what devices are onboarded on their network. You must not only discover the devices but also control their level of access, based on their role, location, and so on. Zero Trust Access 7.2 Study Guide 23  ZTA Overview DO NOT REPRINT © FORTINET Endpoint access and control is an important area of zero trust for on-network devices, as well as for the security and ongoing control of off-network devices. Endpoint agents like FortiClient can be used to ensure endpoints are patched properly, protected from malware, have had their security posture assessed and so on. Secure access to a corporate network can be provided using a VPN with single sign-on (SSO) capabilities. Zero Trust Access 7.2 Study Guide 24  ZTA Overview DO NOT REPRINT © FORTINET In this section, you will learn about ZTNA and the differences between ZTNA and VPN. Zero Trust Access 7.2 Study Guide 25  ZTA Overview DO NOT REPRINT © FORTINET ZTNA, is an element of ZTA. ZTNA allows you to apply zero-trust principles to control which users will access what application over the network. ZTNA eliminates the need for a user to connect to a VPN before accessing an application across data centers or the cloud. Applications are accessed when needed, directly through an access proxy or broker. With ZTNA, a user can more seamlessly work from the office or remotely, which creates a smoother user experience. Zero Trust Access 7.2 Study Guide 26  ZTA Overview DO NOT REPRINT © FORTINET ZTNA connects users to applications, regardless of the user’s location or application. Connection through ZTNA functions as follows: 1. The user wants to access an application and connects to an access proxy. 2. The access proxy creates a secure tunnel automatically between the user and the application. 3. The access proxy authenticates the user and identifies the device and the device posture. 4. After successfully authenticating and meeting the device posture requirements, the access proxy verifies the application access level of the user. 5. The access proxy verifies the access level and grants access to the user. 6. Whenever a new session is established, the access proxy repeats these steps to verify that the user identity, access levels, and device posture have not changed. Zero Trust Access 7.2 Study Guide 27  ZTA Overview DO NOT REPRINT © FORTINET VPNs work at the network layer. When a user connects, a one-time trust check is applied, and then the user has access to network subnets or IP addresses. VPNS are intended to extend corporate networks to remote users, where all the resources and applications used to be on-premises. Now that most applications are on the public cloud, it causes too much overhead on VPN gateways. Trusted networks must be extended to access resources on the public cloud, and too much traffic will traverse the gateway to reach the cloud-based resources. ZTNA changes the underlying VPN model completely. A user can connect directly to an application through an access proxy or broker on an as-needed basis. ZTNA is designed for users on-network and off-network, accessing applications in the data center or on the cloud. ZTNA follows the zero-trust principle of continuously monitoring user authentication, access levels, and device postures. ZTNA is lightweight and less resource intensive than VPN. Zero Trust Access 7.2 Study Guide 28  ZTA Overview DO NOT REPRINT © FORTINET This slide shows the objectives you have covered in this lesson. By mastering the objectives covered in this lesson, you learned ZTA security design principles the differences between ZTNA and ZTA. Zero Trust Access 7.2 Study Guide 29  ZTA Components DO NOT REPRINT © FORTINET In this lesson, you will learn about the zero trust access (ZTA) components. Zero Trust Access 7.2 Study Guide 30  ZTA Components DO NOT REPRINT © FORTINET After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating a competent understanding of ZTA architecture, you will be able to identify the different ZTA components. Zero Trust Access 7.2 Study Guide 31  ZTA Components DO NOT REPRINT © FORTINET In this section, you will review some of the ZTA components. Zero Trust Access 7.2 Study Guide 32  ZTA Components DO NOT REPRINT © FORTINET ZTA is not just one product or platform; it is a solution to control access to assets and applications by users and devices. Some of the key ZTA components include: Identity management: The zero-trust principle of multifactor and continuous authentication is applied. Network access control: Device visibility and centralized access control are implemented. Endpoint protection platform: Device security posture and endpoint vulnerability management are implemented. Next-generation firewall (NGFW): Network traffic is segmented and inspected. NGFW also acts as segmentation gateway. Layer 2 infrastructure: Securing devices on Layer 2 using port security, MAC filtering, and microsegmentation. Zero Trust Access 7.2 Study Guide 33  ZTA Components DO NOT REPRINT © FORTINET In this section, you will get an overview of FortiAuthenticator key authentication features. Zero Trust Access 7.2 Study Guide 34  ZTA Components DO NOT REPRINT © FORTINET FortiAuthenticator is a centralized identity and access management solution. It provides user identity services to the Fortinet Security Fabric and third-party devices. The key authentication features on FortiAuthenticator include RADIUS, LDAP, and 802.1X wireless authentication, certificate management, Security Assertion Markup Language (SAML), and FSSO. FortiAuthenticator is compatible with FortiToken to provide two-factor authentication when using multiple FortiGate and third-party devices. FortiAuthenticator and FortiToken together deliver cost-effective, scalable, secure authentication to your entire network infrastructure. Zero Trust Access 7.2 Study Guide 35  ZTA Components DO NOT REPRINT © FORTINET FortiAuthenticator can store the user database locally. It can also proxy authentication requests from a client to a back-end authentication server. You must configure the following settings: Name, Primary server name/IP, Base distinguished name, Bind type, and administrator Username and Password for regular bind type. Note that the Base distinguished name sets the root node where LDAP starts searching for user accounts. There are predefined LDAP templates you can select in the Server type field. They include default attribute settings for well-known LDAP servers, such as Microsoft Active Directory, OpenLDAP, and Novell eDirectory. If you want FortiAuthenticator to relay CHAP, MSCHAP, and MSCHAPv2 authentication to a Windows AD server, you must enable Windows Active Directory Domain Authentication and enter the credentials for a Windows administrator. FortiAuthenticator logs in to the domain as a trusted device, allowing FortiAuthenticator to proxy CHAP, MSCHAP, and MSCHAP2 authentication, using NTLM. Zero Trust Access 7.2 Study Guide 36  ZTA Components DO NOT REPRINT © FORTINET The slide shows is an example of the configuration required for FortiAuthenticator to proxy authentication requests to a remote RADIUS server. Zero Trust Access 7.2 Study Guide 37  ZTA Components DO NOT REPRINT © FORTINET FortiAuthenticator accepts RADIUS authentication requests from only approved RADIUS clients. After you configure remote authentication servers or a local user database, you must allow FortiGate to make authentication requests to FortiAuthenticator. This is done under RADIUS clients on FortiAuthenticator. After you configure a RADIUS client, you must assign it to one or more RADIUS policies. A RADIUS policy contains the authentication settings that FortiAuthenticator follows when processing authentication requests sent by your RADIUS client. When FortiAuthenticator receives a RADIUS authentication request, it looks at the request attributes and then finds a matching policy using a top-down approach. If there is no matching policy, FortiAuthenticator rejects the RADIUS authentication request. Zero Trust Access 7.2 Study Guide 38  ZTA Components DO NOT REPRINT © FORTINET There are two ways you can add users to FortiAuthenticator: Local users can be created manually on the FortiAuthenticator database or imported from a CSV file or FortiGate configuration file. Remote users can be imported from remote LDAP servers. Zero Trust Access 7.2 Study Guide 39  ZTA Components DO NOT REPRINT © FORTINET Typically, an OTP token is not used as a standalone solution, but as an additional authentication mechanism on top of a user name and static password. OTP tokens generate passwords that can be used only once. They are more secure than static passwords because they are not vulnerable to replay attacks. For example, even if an attacker obtains an OTP, the password invalidates after a short interval (usually 60 seconds). Because memorizing a one-time password is practically impossible, you need something that can generate them for you. There are three main ways of acquiring one-time passwords: Hardware tokens, which are physical devices, such as the FortiToken 200 series Software tokens, which are software applications on a smart phone, such as FortiToken Mobile FortiToken Cloud, which uses cloud-based token validation using FortiToken Mobile Tokenless, which use email or SMS Zero Trust Access 7.2 Study Guide 40  ZTA Components DO NOT REPRINT © FORTINET This slide shows the multitude of ways FortiAuthenticator can identify users over the FSSO framework. The FortiAuthenticator FSSO framework has five layers: The first layer is the identity source: the method by which the user identity is ascertained. The second layer is the identity discovery: the methods by which the user identity and their location (IP) are discovered. You will learn each of these methods in the FSSO User Identity Discovery Methods section. The third layer is aggregation and embellishment: the collection of user identity and addition of any missing information, such as group, which is gathered from the external LDAP/AD. The fourth layer is the communication framework: the method by which the authentication information is communicated with the subscribing device. The fifth layer is the subscribing device: for example, FortiGate. The user information is forwarded to the subscribing device where the information can be used in firewall policies. Note that you can also combine multiple methods. For example, Single Sign-On Mobility Agent may be used for Microsoft Windows domain PCs but fall back to the login portal with embedded widgets for non-Windows systems or unauthenticated PCs. Zero Trust Access 7.2 Study Guide 41  ZTA Components DO NOT REPRINT © FORTINET Some of the standard FortiAuthenticator SSO identification methods include: Active directory polling/domain controller (DC) agent mode: User authentication into an active directory is detected by regularly polling domain controllers. When a user login is detected, the username, IP, and group details are entered into the FortiAuthenticator user identity management database and, according to the local policy, can be shared with multiple FortiGate devices. FortiAuthenticator SSO mobility agent (SSOMA): For complicated distributed domain architectures where the polling of domain controllers is not feasible or desired, an alternative is the FortiAuthenticator SSO client. Distributed as part of FortiClient or as a standalone installation for Windows PCs. FortiAuthenticator portal and widgets: For systems that do not support AD polling or where a client is not feasible, FortiAuthenticator provides an explicit authentication portal. This portal allows the users to authenticate to the FortiAuthenticator manually and subsequently into the network. RADIUS accounting login: RADIUS accounting can be used as a user identification method. This information triggers user login and provides IP and group information, removing the need for a second tier of authentication. Zero Trust Access 7.2 Study Guide 42  ZTA Components DO NOT REPRINT © FORTINET FortiAuthenticator can act as a self-signed or local CA for the creation, signing, and revoking of X.509 certificates. These certificates can be used for VPN authentication, 802.1X authentication, Windows Desktop authentication, and token-based authentication, to name a few. FortiAuthenticator can also act as a SCEP server for: Signing user CSRs Distributing CRLs Distributing CA certificates Acting as an LDAP client, FortiAuthenticator can authenticate users against an external LDAP server. It verifies the identity of the external LDAP server by using a trusted CA certificate. Extensible Authentication Protocol (EAP) is a type of authentication framework often used in wireless networks and point-to-point connections. In this scenario, if a client is attempting to authenticate over EAP, FortiAuthenticator can check that the client’s certificate is signed by one of the configured (and authorized) CA certificates. The client certificate must also match one of the user certificates. Zero Trust Access 7.2 Study Guide 43  ZTA Components DO NOT REPRINT © FORTINET In this section, you will have an overview of FortiNAC and its key features. Zero Trust Access 7.2 Study Guide 44  ZTA Components DO NOT REPRINT © FORTINET FortiNAC is a network access control solution that can be integrated with the Fortinet security fabric to enhance visibility, control, and automated response for everything that connects to the network. FortiNAC scans the network to detect and classify devices through agent or agentless to enforce dynamic network access control and segmentation. Zero Trust Access 7.2 Study Guide 45  ZTA Components DO NOT REPRINT © FORTINET FortiNAC scans your network to discover every user, application, and device. With up to twenty one different techniques, FortiNAC can then profile each element based on observed characteristics and responses. Scanning can be done actively or passively and can utilize permanent agents, dissolvable agents, or no agents. Additionally, FortiNAC can assess a device to see if it matches approved profiles, noting the need for software updates to patch vulnerabilities. Zero Trust Access 7.2 Study Guide 46  ZTA Components DO NOT REPRINT © FORTINET FortiNAC enables detailed segmentation of the network to enable devices and users access to necessary resources while blocking non-authorized access. FortiNAC uses dynamic role-based network access control to logically create network segments by grouping applications and like data together to limit access to a specific group of users and/ or devices. FortiNAC validates a device’s configuration as it attempts to join the network to ensure integrity before they connect to the network minimizes risk and the possible spread of malware. Zero Trust Access 7.2 Study Guide 47  ZTA Components DO NOT REPRINT © FORTINET FortiNAC will monitor the network on an ongoing basis, evaluating endpoints to ensure they conform to their profile. FortiNAC can watch for anomalies in traffic patterns. This passive anomaly detection works in conjunction with FortiGate appliances. Once a compromised or vulnerable endpoint is detected as a threat, FortiNAC triggers an automated response to contain the endpoint in realtime. Zero Trust Access 7.2 Study Guide 48  ZTA Components DO NOT REPRINT © FORTINET In this section, you will have an overview of FortiClient EMS and FortClient. Zero Trust Access 7.2 Study Guide 49  ZTA Components DO NOT REPRINT © FORTINET FortiClient EMS is a security management solution that enables scalable and centralized management of multiple endpoints. It also provides efficient and effective administration of endpoints running FortiClient, and visibility across the network to securely share information and assign security profiles to off-fabric and on- fabric endpoints. It is designed to maximize operational efficiency and includes automated capabilities for device management and troubleshooting. Some of the key features that FortiClient EMS can provide to FortiClient endpoint are zero-trust telemetry, zero trust network access (ZTNA), remote access, endpoint protection, and so on. Zero Trust Access 7.2 Study Guide 50  ZTA Components DO NOT REPRINT © FORTINET The Zero Trust Telemetry tab displays whether FortiClient telemetry is connected to EMS. You can use the Zero Trust Telemetry tab to manually connect FortiClient telemetry to EMS and to disconnect FortiClient telemetry from EMS. When zero trust telemetry is connected to EMS, FortiClient collects the hardware information (MAC addresses), software information (OS version on the endpoint), identification information (username, avatar, and hostname), and vulnerability information that the vulnerability scanning module reports about the endpoint and its workload, and sends to EMS. When EMS participates in the Security Fabric, the Security Fabric uses the information to understand the endpoint and its workload to better protect it. Zero Trust Access 7.2 Study Guide 51  ZTA Components DO NOT REPRINT © FORTINET Zero trust tags can dynamically group endpoints based on their operating system version, logged-in domains, and so on. After these tags are automatically synced with FortiOS, network traffic can be allowed or denied based on these tags. Zero Trust Access 7.2 Study Guide 52  ZTA Components DO NOT REPRINT © FORTINET FortiClient EMS has a default_ZTNARootCA certificate generated by default that the ZTNA CA uses to sign CSRs from the FortiClient endpoints. Clicking the refresh button revokes and updates the root CA, forcing updates to the FortiGate and FortiClient endpoints by generating new certificates for each client. FortiClient EMS can also manage individual client certificates. You can also revoke the certificate that is used by the endpoint when certificate private keys show signs of being compromised. Click Endpoint > All Endpoints, select the client, and then click Action > Revoke Client Certificate. Do not confuse the FortiClient EMS CA certificate (ZTNA) with the SSL certificate. The latter is the server certificate that is used by FortiClient EMS for HTTPS access and fabric connectivity to the FortiClient EMS server. Zero Trust Access 7.2 Study Guide 53  ZTA Components DO NOT REPRINT © FORTINET ZTNA connection rules on FortiClient create a secure encrypted connection to protected applications without using VPN. FortiClient uses the FortiGate device application proxy feature to create a secure connection through HTTPS using a certificate received from EMS that includes the FortiClient UID. FortiGate acts as a local proxy gateway. FortiGate retrieves the UID to identify the device and check other endpoint information that EMS provides to FortiGate, which can include other identity and posture information. FortiGate allows or denies the access, as applicable. Zero Trust Access 7.2 Study Guide 54  ZTA Components DO NOT REPRINT © FORTINET FortiClient provides comprehensive endpoint protection for your Windows-based, MAC-based, and Linux- based desktops, laptops, file servers, and mobile devices, such as iOS and Android. It helps you to safeguard your systems with advanced security technologies, all of which you can manage from a single management console. Zero Trust Access 7.2 Study Guide 55  ZTA Components DO NOT REPRINT © FORTINET FortiClient supports both IPsec and SSL VPN connections to your network for remote access. The FortiClient EMS administrator can provision client VPN connections in the FortiClient profile (EMS endpoint profile) or the endpoint user can configure new connections on the FortiClient console. You can also configure two-factor authentication using FortiToken for enhanced security for both types of VPNs on your FortiGate for FortiClient VPN connections. Zero Trust Access 7.2 Study Guide 56  ZTA Components DO NOT REPRINT © FORTINET In this section, you will have an overview of Fortinet’s LAN edge devices. Zero Trust Access 7.2 Study Guide 57  ZTA Components DO NOT REPRINT © FORTINET A key enabling technology is FortiLink; it is what enables Fortinet’s unique capabilities at the LAN edge. FortiLink protocols allows FortiGate to be able to manage Fortinet’s network access layer. You can manage, control, and configure FortiAPs and FortiSwitches directly through FortiOS. No additional licensing is required for you to be able to use FortiLink to manage your network access layer. Zero Trust Access 7.2 Study Guide 58  ZTA Components DO NOT REPRINT © FORTINET Managing FortiSwitch devices using FortiGate offers the following important key benefits: Zero-touch provisioning: When you connect FortiSwitch to a FortiGate interface that has FortiLink enabled, FortiGate automatically discovers and provisions FortiSwitch. You can also use zero-touch provisioning by configuring the FortiGate settings on FortiManager. Single pane management: You can manage FortiSwitch using the FortiGate GUI and CLI, or using FortiManager. Administrators are not required to log in to FortiSwitch. Security Fabric integration with FortiLink: FortiSwitch becomes an extension of FortiGate. You configure firewall policies using FortiSwitch VLANs in the same way as for FortiGate VLANs. Authentication and authorization are also handled centrally on FortiGate or FortiManager. Virtual stacking: FortiGate can manage multiple FortiSwitch devices stacked in different ways, to offer redundancy. Scalability: FortiGate and FortiSwitch devices come in many sizes to accommodate the needs of customers, from retail and SMB, up to data centers. Zero Trust Access 7.2 Study Guide 59  ZTA Components DO NOT REPRINT © FORTINET Managing FortiAP devices using FortiGate offers the following important key benefits: Zero-touch deployment: When you connect FortiAP to a FortiGate interface that has FortiLink enabled, FortiGate automatically discovers and authorizes the FortiAP. There are no additional license required to mange FortiAPs from FortiGate. Single pane management: You can manage FortiAP using the FortiGate GUI or on FortiManager. Administrators are not required to log in to FortiAP. Security fabric integration with fortilink: You configure firewall policies using FortitAP SSIDs in the same way as for FortiGate interfaces. Authentication and authorization are also handled centrally on FortiGate or FortiManager. Scalability: FortiAPs are available in range of platforms to support any size of deployments. Zero Trust Access 7.2 Study Guide 60  ZTA Components DO NOT REPRINT © FORTINET You can segment your network subnets into different VLANs based on departments, roles, and so on. FortiGates can allow or deny traffic between different VLANs on managed FortiSwitches using firewall policies. Zero Trust Access 7.2 Study Guide 61  ZTA Components DO NOT REPRINT © FORTINET You can block intra-VLAN traffic on FortiSwitches managed by FortiGates. This prevents direct client-to-client traffic visibility at the Layer2 VLAN layer. Clients can communicate with FortiGate. After the client traffic reaches the FortiGate, FortiGate determines whether to allow various levels of access to the client by shifting the client's network VLAN as appropriate, if allowed by a firewall policy, and if proxy ARP is enabled. You can also block intra-SSID traffic on the FortiAPs managed by FortiGates. This will restrict communication between two wireless clients connected on same SSID on FortiAPs. Zero Trust Access 7.2 Study Guide 62  ZTA Components DO NOT REPRINT © FORTINET You can enable 802.1x authentication through security policies on FortiSwitch. Port-based authentication is preferred when you expect a single host per port to authenticate, even though there may be multiple hosts connecting to the same port. In this scenario, FortiSwitch authenticates a single host, and opens the port to other devices behind the port. A use case for this scenario is an access point (AP). After an AP authenticates against the switch, any of its connected devices can access the network, despite them using a different MAC address from the one used by the AP during authentication. In addition, all devices are granted the same access level assigned to the AP. However, if you want to authenticate each device behind a port, and optionally, grant each device a different access level based on the credentials provided, then MAC-based is required. For security, MAC-based authentication is preferred because each host (or MAC address) behind the port must authenticate to access the network. For performance, port-based is better because only a single host is required to authenticate. Alternatively, you can enable MAC authentication bypass to allow access to a non-802.1X device, provided the device MAC address is authorized on the authentication server. FortiAP supports dynamic user VLAN assignment, and is available when using enterprise security mode with RADIUS authentication. VLAN assignment by RADIUS is used to assign each user to a VLAN based on information stored in the RADIUS authentication server. VLANs can also be set dynamically based on FortiAP groups. Dynamic VLAN assignment allows the same SSID to be deployed to many APs, avoiding the need to produce multiple SSIDs. VLAN assignment by VLAN pool assigns multiple VLANs to a single SSID removing any client limit and preserving an efficient IP network. Zero Trust Access 7.2 Study Guide 63  ZTA Components DO NOT REPRINT © FORTINET In this section, you will have an overview of the FortiGate ZTNA features. Zero Trust Access 7.2 Study Guide 64  ZTA Components DO NOT REPRINT © FORTINET ZTNA access proxy allows users to securely access resources through an SSL-encrypted access proxy by eliminating the user of dial-up IPSEC VPNs. FortiGate can act as an access proxy and supports the following methods: HTTPS access proxy: works as a reverse proxy for the HTTP server. When a client connects to a web page hosted by the protected server, the address resolves to the FortiGate access proxy virtual IP (VIP). FortiGate proxies the connection and takes steps to authenticate the device. It prompts the user for the endpoint certificate on the browser, and verifies this against the ZTNA endpoint record that is synchronized from the FortiClient EMS. TCP forwarding access proxy (TFAP): is configured to demonstrate an HTTPS reverse proxy that forwards TCP traffic to the designated resource. The access proxy tunnels TCP traffic between the client and FortiGate over HTTPS, and forwards the TCP traffic to the protected resource. It verifies user identity, device identity, and trust context, before granting access to the protected source. ZTNA rules needs to configured on FortiClient endpoints. Zero Trust Access 7.2 Study Guide 65  ZTA Components DO NOT REPRINT © FORTINET ZTNA tags are configured and generated using tagging rules on FortiClient EMS. FortiGate connects to FortiClient EMS through the Security Fabric and automatically synchronises the ZTNA tags. FortiGate can uses the ZTNA tags in firewall policies or ZTNA rules, to allow or deny network traffic. Zero Trust Access 7.2 Study Guide 66  ZTA Components DO NOT REPRINT © FORTINET This slide demonstrates ZTNA telemetry, tags, and policy enforcement. You configure ZTNA tag conditions and policies on FortiClient EMS. FortiClient EMS shares the tag information with FortiGate through Security Fabric integration. FortiClient communicates directly with FortiClient EMS to continuously share device status information through ZTNA telemetry. FortiGate can then use ZTNA tags to enforce access control rules to incoming traffic through ZTNA access. Zero Trust Access 7.2 Study Guide 67  ZTA Components DO NOT REPRINT © FORTINET This slide shows the objectives you have covered in this lesson. By mastering the objectives covered in this lesson, you learned about the different ZTA components. Zero Trust Access 7.2 Study Guide 68  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET In this lesson, you will learn about the zero trust access (ZTA) design principles for securing network access with FortiNAC. Zero Trust Access 7.2 Study Guide 69  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating competence in design principles for securing network access with FortiNAC, you will understand the key features of implementing FortiNAC. Zero Trust Access 7.2 Study Guide 70  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET In this section, you will have an overview of FortiNAC and its deployment options. Zero Trust Access 7.2 Study Guide 71  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET Fortinet believes that the visibility and control that network access control (NAC) provides are foundational to security at the edges of your network. Fortinet offers the following NAC solutions: FortiLink NAC, as a feature of our LAN Edge (Fortinet wired and wireless) solution, for free. This feature provides base-level discovery and control. Fortinet’s core offering is FortiNAC which offers a full-featured solution that encompasses not only Fortinet equipment, but also a variety of leading vendors equipment, to provide a solution to secure networks and integrate them into the Security Fabric. Zero Trust Access 7.2 Study Guide 72  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET FortiNAC is a flexible and scalable solution that spans mid-sized to large enterprise deployments. There are three components in a FortiNAC deployment: Application and control: The network application and control server (NCAS) is where all the NAC functions are running. Management: FortiNAC Control Manager is suitable for large distributed environments. When deployed as a network control manager, FortiNAC can manage other FortiNAC devices. Reporting: FortiAnalyzer can be used for centralized logging. You can configure and deploy FortiNAC using the NCAS; this is the only required component. FortiNAC control manager and FortiAnalyzer are optional components and can be deployed, depending on your organization's requirements. Zero Trust Access 7.2 Study Guide 73  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET FortiNAC offers three different license types. FortiNAC base includes network discovery, host profiling, and classification. FortiNAC plus consists of host registration, scanning, and access control, along with all base features. FortiNAC pro includes automated threat response (security Incidents), and all the plus and base features. FortiNAC pro license is recommended for comprehensive ZTA features. Zero Trust Access 7.2 Study Guide 74  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET FortiNAC Control Manager provides the ability to manage multiple FortiNAC devices. FortiNAC devices are added for management, individually, to the FortiNAC Control Manager. FortiNAC Control Manager can then update all managed FortiNAC devices to ensure that each device is operating with the same revision. Licensing is pushed down from the FortiNAC Control Manager to the FortiNAC devices that it manages, dynamically distributing the concurrent license counts as needed. This architecture allows FortiNAC to scale to even the largest environments. Global management and visibility provide a single, simplified administration in large distributed deployments. Zero Trust Access 7.2 Study Guide 75  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET You can deploy FortiNAC as a physical device or as a virtual machine. FortiNAC communicates with infrastructure devices, such as wireless controllers, autonomous APs, switches, routers, and others. Because these infrastructure devices are inline, they can detect connected devices and connecting endpoints. They send this information back to FortiNAC, or FortiNAC gathers this information from them. FortiNAC uses a variety of methods to communicate with and gather information from, the infrastructure: FortiNAC uses SNMP to discover the infrastructure, complete data collection, and perform ongoing management. SSH or Telnet through the CLI is commonly used to complete tasks related to the infrastructure. For example, FortiNAC can use SSH to connect to a device and issue commands to gather visibility information or execute control functions. FortiNAC can also use RADIUS across a wired or wireless connection, to gather visibility information and control access. FortiNAC uses syslog to stay up-to-date on visibility details, such as hosts going offline. Syslog can also provide security device integration, giving FortiNAC the ability to log and react, if configured to do so, when it receives a security alert. Depending on the vendor of the infrastructure device, FortiNAC may leverage available API capabilities to enhance visibility and enforce control. FortiNAC can use DHCP, typically through fingerprinting, to identify connected devices and gain enhanced visibility. The communication methods that FortiNAC uses depend on the vendor and model of the infrastructure device that FortiNAC is trying to integrate with. After FortiNAC knows the type of device it is communicating with, it determines and uses the appropriate methods and commands to gather information and maintain control. Zero Trust Access 7.2 Study Guide 76  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET This slide shows how FortiNAC can be integrated into the ZTA architecture, along with the other ZTA components. Zero Trust Access 7.2 Study Guide 77  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET In this section, you will learn about FortiNAC management configuration. Zero Trust Access 7.2 Study Guide 78  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET There are four key configuration stages in a FortiNAC deployment: Management configuration is where all the administrative tasks are carried out, like licensing, configuring management interfaces, uploading SSL certificates for agent communication, captive portal, and so on. The configuration wizard is used to define the FortiNAC captive networks. Network modeling is where you will add the devices for the endpoints to be connected, for example, FortiGate, FortiSwitch, FortiAP. To model devices, FortiNAC requires SNMP and ICMP connectivity to these devices. Device onboarding is where devices are detected and profiled, for example, corporate device, BYOD, IoT. After the device is detected and profiled, the device is registered and provided with different access levels based on policy configuration. Policy configuration decides the different access levels that can be provided to a device, based on device profiles, endpoint compliance, and so on. Zero Trust Access 7.2 Study Guide 79  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET This slide shows some of the key points you should remember while configuring FortiNAC. Zero Trust Access 7.2 Study Guide 80  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET This slide shows some more key points related to FortiNAC configuration. Zero Trust Access 7.2 Study Guide 81  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET Depending on the SSL function, you can use an SSL certificate signed by a public or private CA on FortiNAC. This slide shows when different CA’s can be used on the FortiNAC. For FortiNAC administration interface and persistent agent, you can use an SSL certificate issued by a private or public CA. FortiNAC administration interface is usually accessed through corporate devices, and the certificates can be easily managed. The SSL certificate used for the persistent agent is also easy to manage as they are usually deployed on managed devices. Using SSL certificates signed by a public CA for the captive portal is recommended to avoid certificate errors, because it will be mostly unmanaged guest devices that will be accessing the network. For EAP and EAP-TLS it is recommended to use certificates with subject alternate name (SAN) and avoid wildcard certificates. Zero Trust Access 7.2 Study Guide 82  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET In this section, you will review the FortiNAC access layer operations. Zero Trust Access 7.2 Study Guide 83  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET For network modeling, you need to add devices that the endpoints connect to the FortiNAC device inventory. FortiNAC requires ICMP or PING connectivity to the device that needs to be added. To carry out remote tasks like manual polling, scheduled tasks, and link traps, FortiNAC almost always needs SNMP and CLI read-write access to the device. When you add devices to the device inventory, always click Validate Credentials to confirm that SNMP and CLI connectivity is established to the device. Ensure that PING, SNMP, HTTPS, and SSH are enabled on the FortiGate management interface, and that FortiNAC is added as an SNMP host to be added to the FortiNAC device inventory. Ensure authentication and privacy protocol matches, if using SNMPv3. Zero Trust Access 7.2 Study Guide 84  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET FortiNAC captive networks are those networks used for the isolation of hosts, and the presentation of captive portals. There are seven types of captive networks: Registration VLAN is used to isolate unregistered rogue devices. Remediation VLAN is used to quarantine devices that failed endpoint compliance. Disabled hosts are placed in dead end VLAN. Authentication VLAN is used to isolate registered clients from the production network during user authentication. Virtual private network (VPN) is used for clients who connect to the network through VPN services. Access point management is used for clients that connect through devices managed by access point management. Isolation VLAN uses the state of the client and redirects them to the appropriate isolation web pages. If you use this VLAN type, the configuration of the other VLAN types are optional. Zero Trust Access 7.2 Study Guide 85  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET The logic used by FortiNAC when making the decision to isolate a host is summarized on this slide. When an endpoint connects to the network, FortiNAC looks it up in the database to determine its state. If the host does not exist in the database, and it does not match any enabled device profiling rules, it will be added and assigned the state of rogue. FortiNAC uses the If Host State is column as the column to key on, starting at the top and working down. For example, if a host with a state of Rogue connects to the network, FortiNAC uses the third row down to determine if isolation is necessary. After the appropriate row is identified, FortiNAC reads from left to the right, applying AND logic between the If Host State is and And System Group Membership is columns. If both columns in the same row, are true, then FortiNAC moves the host to the captive network shown in the Then Change VLAN to column. On the GUI, the host is represented by the icon shown in the associated row of the Icon column. For example, if a host with the state of Rogue connects to a port in the Forced Registration port group, FortiNAC will isolate that host by moving it into the Registration captive network. The top four rows all function in the same way, with the slight exception of the first row, where the location parameter is defined by a device group, not a port group. The bottom three rows consist of two special captive networks, and a row where hosts with a state of normal are provisioned. Zero Trust Access 7.2 Study Guide 86  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET This slide shows an example of how logical networks can be used. In the example, six network access policies have been developed to support the required endpoint-based segmentation on four infrastructure devices. As you can see, a device identified as a camera and assigned to the logical network Camera is provisioned to VLAN 80, if it connects to Switch-1; is provisioned to VLAN 81, if it connects to Switch-2; and so on. The values designated in the AP-1 column are access values that may be vendor specific, depending on the vendor of the wireless access point (AP) or controller. These values could also be VLAN names, groups, roles, interfaces names, and so on. The Firewall column could represent a firewall tag that would result in the camera matching a specific firewall policy. You can use logical networks to greatly decrease the number of network access policies, resulting in simplified policy creation and management. These same network access policies work for small, medium, or large environments. Zero Trust Access 7.2 Study Guide 87  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET In this section, you will learn about device management on FortiNAC. Zero Trust Access 7.2 Study Guide 88  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET Device detection is performed by FortiNAC to determine what devices are connected to the network using Layer 2 and Layer 3 data polling methods. The three ways that Layer 2 polling is triggered are: Manual polling: Manual polling is initiated when an administrative user right-clicks the device in the topology tree and selects Poll for L2 (Hosts) Info, or clicks Network > L2 Polling. Scheduled: Layer 2 polling is scheduled in the Network > L2 Polling view. You can change the default scheduled intervals. Link traps: Link traps received from an edge device trigger FortiNAC to perform a Layer 2 poll to update its awareness of devices that are connected on that edge device. The traps that trigger the poll are: Linkup, Linkdown, WarmStart, and ColdStart. This trigger keeps FortiNAC up-to-date in real time as devices connect to and disconnect from edge devices. Layer 3 IP address information is a critical piece of network visibility and is a necessary component for some FortiNAC capabilities. Layer 3 devices are polled for MAC address to IP address correlation using the ARP table. With the information collected from Layer 2 and Layer 3 data polling, a host record is populated on FortiNAC with the device MAC and IP address (what), switch port the device is connected to (when), and the time it connected (when). Zero Trust Access 7.2 Study Guide 89  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET The methods shown on this slide are used to evaluate connected rogue devices. If more than one method is selected, the selected methods are logically added when determining if the rule is matched. Match criteria are configured for each method, because the methods are selected. The classification settings outline how FortiNAC will configure the connected device and how it will appear in the GUI. You can leverage the device type, role, and group membership for policy enforcement. You can use access availability settings to grant networks access during specific days and times, and the Rule Confirmation option to revalidate previously profiled devices. Zero Trust Access 7.2 Study Guide 90  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET In this section, you will learn about user identification and the captive portal on FortiNAC. Zero Trust Access 7.2 Study Guide 91  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET To identify the user information, FortiNAC has an authentication VLAN for user self registration. The users can be authenticated using either a local user database on FortiNAC or remote user databases like LDAP, RADIUS, Google, and social media sites integrations using API. FortiNAC supports two RADIUS authentication methods—local RADIUS and proxy RADIUS. Local service has all the components needed to manage RADIUS connections MAB, EAP-TLS, and PEAP within FortiNAC. The proxy can be used for MAC address bypass without any need to proxy requests, and it will proxy EAP requests to another RADIUS server, for example, Microsoft NPS, FortiAuthenticator, and so on. Traditional RADIUS authentication ports— 1812 or 1645—can be defined on either service, but you cannot assign the same port number to proxy and local service simultaneously. The authentication method specified in the authentication policy will override all other authentication methods configured in the portal, on the guest or contractor template, and persistent agent credential configuration. Zero Trust Access 7.2 Study Guide 92  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET When hosts have been assigned to a captive network, they will be directed to a captive portal page. The page presents the user with additional information and/or capabilities, to resolve the non-normal host state. For example, a rogue host isolated to the registration captive network will be presented, by default, with a registration page that provides options for onboarding the host. The onboarding process will classify the host. When a host is isolated on a wired port, FortiNAC will shut down the port causing the host’s link to drop, the VLAN to change, and the port to be re-enabled. This will result in the host requesting a new IP address, which begins the captive portal page presentation process. This process is shown on the slide as a timeline going from left to right. First, the host gets a new IP address appropriate for the captive network it is in, with a DNS address that is the FortiNAC captive portal interface. When the host attempts to resolve a domain by name, FortiNAC, which has been designated as the DNS server, will respond with its own address, masquerading as the domain the host is attempting to resolve. This is the result of special root.hint files on FortiNAC. FortiNAC will then present the appropriate captive portal page to the isolated host. Note that there are ways to allow specific sites to resolve correctly. Zero Trust Access 7.2 Study Guide 93  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET In this section, you will review policy and security rules on FortiNAC. Zero Trust Access 7.2 Study Guide 94  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET A security policy is composed of two different pieces. The first is the user/host profile, which is the piece that identifies if a user or host matches a particular policy. The second piece is the configuration, which is the policy-specific settings applied if the associated user/host profile is matched. User/host profiles are a set of FortiNAC visibility parameters—the who, what, where, and when information. These profiles can range from general to very specific, keying upon individual attributes, and applying AND, OR, and NOT logic. You can associate five different types configurations with a user/host profile: Portal Authentication Network access Endpoint compliance Supplicant EasyConnect Hosts and users are continuously evaluated to identify if a user/host profile matches. Whenever FortiNAC identifies a match, the highest ranked security policy of each type, if any, are applied. For example, if a user matches a user/host profile that identifies guest users, and that user/host profile is associated with a network access configuration, the configuration settings are applied, provisioning the access appropriately. Zero Trust Access 7.2 Study Guide 95  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET For endpoint compliance and application gathering, you can either use the FortiNAC agent or with integration of a mobile device management (MDM) system like FortiClient EMS. FortiNAC has three different types of endpoint agents. The persistent agent is installed on managed devices and stays resident on the endpoint. The dissolvable agent is a run once agent and requires manual end-user interaction within the captive portal. Once it completes and reports its results, it dissolves and leaves no footprint on the endpoint. This is a common choice for guests, contractors, or BYOD devices. The mobile agent is installed manually within the captive portal during the onboarding process and is the only agent option for Android devices. FortiNAC agents help you register the device on the network, gather application inventory, and do endpoint scans and compliance checks. All this information collected from the endpoint helps to determine the level of network access the user should be granted. Zero Trust Access 7.2 Study Guide 96  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET Understanding the terminology used, and a fairly detailed explanation of the process, goes a long way in understanding how the FortiNAC security rules work, and simplifies their development. Starting with the top row in the example shown on this slide, and reading left to right, the process begins with the receipt of a security alert. A security alert is the syslog message received from an integrated security device. The alert is processed by FortiNAC, which means that the message contents are parsed and each component evaluated. The contents are then compared to all existing filters. A filter is a user-created set of criteria. For example, a filter could simply look at the contents of column 35 of the parsed security alert and check to see if the value matches the defined requirement. Or, it could require the match of many columns of information. If no filter is matched, the process exits and nothing occurs. If a filter is matched, a security event is generated. In this next step, FortiNAC evaluates all security triggers. A security trigger is made up of one or more filters. Logic can be applied if there is more than one filter making up a trigger, for example, one, all, or a subset of the filters may need to be matched within a defined period of time. If all criteria are matched for the trigger to be satisfied, FortiNAC evaluates any associated user/host profiles. These are the same profiles covered in the security policy lesson. Just as before, they are used here to leverage who, what, where, and when visibility information. The inclusion of a user/host profile allows an administrator to create different workflows for different endpoints, even if the trigger being matched is the same. If both the trigger and any associated user/host profile are satisfied, a security alarm is created. The final step is were the workflows can be defined. If the security rule has an associated action, that action can be carried out in an automated or manual manner. Actions are one or more activities. These activities are the automated responses, and can include notification actions, network access actions, or script execution. Zero Trust Access 7.2 Study Guide 97  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET This slide shows the network access workflow of FortiNAC. When a device tries to connect to the network, FortiNAC identifies the devices using device profiling rules, NMAP scanning, agents, or service connectors like MDM. After the device is identified, you will need to determine what type of authentication will be used and what authentication database—local or remote you should use to authenticate the user. Then FortiNAC uses the information gathered from agents or MDM to determine if the device is compliant. Finally, if the endpoint is determined safe, it can be assigned access, based on different security rules. Zero Trust Access 7.2 Study Guide 98  Securing Network Access with FortiNAC DO NOT REPRINT © FORTINET This slide shows the objectives you have covered in this lesson. By mastering the objectives covered in this lesson, you learned the design principles for securing network access with FortiNAC and the key features of implementing FortiNAC. Zero Trust Access 7.2 Study Guide 99  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET In this lesson, you will learn about zero trust network access (ZTNA) configuration. Zero Trust Access 7.2 Study Guide 100  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET After completing this lesson, you should be able to achieve the objectives shown on this slide. By demonstrating competence in ZTNA, you will be able to identify the ZTNA components and how to configure ZTNA. Zero Trust Access 7.2 Study Guide 101  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET In this section, you will identify the ZTNA components. Zero Trust Access 7.2 Study Guide 102  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET The Fortinet ZTNA solution includes mandatory core products like FortiGate, FortiClient EMS, and FortiClient endpoint, and recommended products like FortiAuthenticator and FortiToken. FortiOS running 7.0 or later firmware can act as a ZTNA access proxy. FortiOS maintains a continuous connection to FortiClient EMS to synchronize endpoint information and ZTNA tags. FortiOS can use these ZTNA tags to grant or deny access to the network. ZTNA licensing is included with FortiOS. FortiClient EMS running 7.0 or later firmware supports ZTNA. FortiClient EMS uses ZTNA tags for device and security postures of managed endpoints. This information from the managed endpoints is shared with FortiGate. FortiClient EMS also generates and installs client certificates on managed endpoints to uniquely identify each endpoint. Zero Trust Access 7.2 Study Guide 103  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET A FortiClient endpoint registers on FortiClient EMS using Zero Trust Telemetry and shares its device information, user information, and security postures. FortiClient uses the certificates it receives from FortiClient EMS to identify itself to FortiGate. ZTNA is supported on FortiClient with 7.0 or later firmware. FortiAuthenticator can provide network and user identity authentication services. You can use FortiToken for multi-factor authentication. These two components are not part of the ZTNA core products but are recommended products. Zero Trust Access 7.2 Study Guide 104  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET In this section, you will learn about ZTNA configuration. Zero Trust Access 7.2 Study Guide 105  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET ZTNA is an access control method that uses client device identification, authentication, and zero-trust tags to provide role-based application access. ZTNA allows administrators to manage network access for on-fabric local users and off-fabric remote users. ZTNA grants access to applications only after device verification, authenticating the user’s identity, authorizing the user, and then performing context-based posture checks using zero-trust tags. Fortinet leverages the existing on-premises FortiGate as part of the ZTNA solution, making it cost effective. There are no additional licenses required to run ZTNA, it is a feature that you can turn on FortiOS and FortiClient EMS. Zero Trust Access 7.2 Study Guide 106  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET This slide shows the flow of events when FortiGate provides access to an off-fabric client using ZTNA. 1. FortiClient endpoints register on FortiClient EMS and share device information, log-on user information, and security posture over ZTNA telemetry with the FortiClient EMS server. Clients also make a certificate signing request to obtain a client certificate from the EMS that is acting as the ZTNA Certificate Authority (CA). 2. FortiClient EMS collects the information to create ZTNA tags and signs the client certificate. 3. FortiClient EMS synchronizes the FortiClient certificate information and ZTNA tags with FortiGate. 4. FortiClient endpoint sends a request to access the application on the protected server. 5. FortiGate performs a device check by verifying if the certificate provided by FortiClient matches the certificate on FortiGate. FortiGate then performs a user check against FortiAuthenticator and a posture check based on the ZTNA tags. 6. After the endpoint passes all of these verifications, FortiGate provides access to the application on the protected server. Zero Trust Access 7.2 Study Guide 107  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET You can configure the on-premises FortiClient EMS connector on FortiGate by clicking Security Fabric > Fabric Connectors. After applying the FortiClient EMS settings, FortiGate must accept the FortiClient EMS server certificate. However, when you configure a new connection to the FortiClient EMS server, the certificate might not be trusted. To resolve this issue, you must manually export and install the root CA certificate on FortiGate. The FortiClient EMS certificate that is used by default for the SDN connection is signed by the CA certificate that is saved on the Windows server when you first install FortiClient EMS. This certificate is stored in the Trusted Root Certification Authorities folder on the server. Next, you must authorize FortiGate on FortiClient EMS. If you log in to FortiClient EMS, a pop-up window opens, requesting you to authorize FortiGate. If you do not log in, you can click Administration > Devices, select the FortiGate device, and then authorize it. Note that the FortiClient EMS connector status appears to be down until you authorize FortiGate on FortiClient EMS. FortiGate automatically synchronizes ZTNA tags after it connects to FortiClient EMS. Zero Trust Access 7.2 Study Guide 108  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET FortiClient must connect to FortiClient EMS. You can verify connection status on the FortiClient console in the ZERO TRUST TELEMETRY menu, or on FortiClient EMS by clicking Endpoints > All Endpoints. To provide connectivity to the remote FortiClient endpoints, you must allow access to port 8013 on the FortiClient EMS through the corporate firewall. On FortiGate, you can create a VIP and inbound policy to allow access to TCP port 8013 from the internet. Zero Trust Access 7.2 Study Guide 109  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET FortiClient EMS has a default_ZTNARootCA certificate generated by default that the ZTNA CA uses to sign CSRs from the FortiClient endpoints. Clicking the refresh button revokes and updates the root CA, forcing updates to the FortiGate and FortiClient endpoints by generating new certificates for each client. FortiClient EMS can also manage individual client certificates. You can also revoke the certificate that is used by the endpoint when certificate private keys show signs of being compromised. In Windows, FortiClient automatically installs certificates into the certificate store. The certificate information in the store, such as certificate UID and SN, should match the information on FortiClient EMS and FortiGate. To locate certificates on other operating systems, consult the vendor documentation. You can use the CLI command diagnose endpoint record list to verify the presence of a matching endpoint record, and information such as the client UID, client certificate SN, and EMS certificate SN on FortiGate. If any of the information is missing or incomplete, client certificate authentication might fail because FortiClient cannot locate the corresponding endpoint entry. Zero Trust Access 7.2 Study Guide 110  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET In earlier versions of FortiClient EMS, on-fabric detection rules was known as on-net detection rules. You can configure on-fabric detection rules for endpoints. FortiClient EMS uses the rules to determine if the endpoint is on fabric or off fabric. Depending on the endpoint on-fabric status, FortiClient EMS may apply a different profile to the endpoint, as configured in the applied endpoint policy. A rule set is available for on-fabric detection. If you configure rules of multiple detection types for a rule set, the endpoint must satisfy all configured rules to satisfy the entire rule set. Zero Trust Access 7.2 Study Guide 111  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET This slide shows an example of an on-fabric rule using the rule type Local IP/Subnet. The Criteria to match is 10.122.0.0/16. The FortiClient endpoint has an IP address of 10.122.0.139. This matches the on-fabric rule set and is tagged as an on-fabric device. A different endpoint profile is assigned to on-fabric and off-fabric devices per this configuration. Zero Trust Access 7.2 Study Guide 112  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET Zero-trust tags determines the security posture of an endpoint running FortiClient. Zero-trust tags are configured through zero-trust tagging rules on FortiClient EMS. You can create zero-trust tagging rules for Windows, macOS, and Linux endpoints based on their OS versions, antivirus software installation, logged in domains, running processes, and other criteria. FortiOS maintains a continuous connection to FortiClient EMS and syncs the zero-trust tags automatically for compliance checks. FortiOS receives endpoint information and enforces compliance only for directly connected endpoints. Directly connected endpoints that have FortiGate as the default gateway. This feature also works for endpoints that are connected to a VPN tunnel as long as they can access FortiClient EMS and the FortiOS. Zero Trust Access 7.2 Study Guide 113  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET You can create, edit, and delete zero-trust tagging rules for Windows, macOS, Linux, iOS, and Android endpoints. Zero Trust Access 7.2 Study Guide 114  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET The Manage Tags window displays all configured tags and the rules that apply the tags to endpoints that satisfy the rule. You can delete tags that do not have any rules attached. Zero Trust Access 7.2 Study Guide 115  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET This slide show the zero-trust tags workflow. The following happens when using zero-trust tagging rules with FortiClient EMS and FortiClient: FortiClient EMS sends zero-trust tagging rules to endpoints through telemetry communication. FortiClient checks endpoints using the provided rules and sends the results to FortiClient EMS. FortiClient EMS dynamically groups endpoints together using the tag configured for each rule. Zero Trust Access 7.2 Study Guide 116  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET To enable ZTNA on the GUI, you must enable the feature on FortiGate System > Feature Visibility, and then enable Zero Trust Network Access. ZTNA configuration on FortiGate requires the following configuration: Add FortiClient EMS as a fabric connector in the Security Fabric. FortiGate maintains a continuous connection to the FortiClient EMS server to synchronize endpoint device information, and also automatically synchronizes ZTNA tags. You can create groups and add tags to use in the ZTNA rules and firewall policies. The ZTNA server defines the access proxy VIP and the real servers that clients connect to. The firewall policy matches and redirects client requests to the access proxy VIP. You can also enable authentication. A ZTNA rule is a proxy policy used to enforce access control. You can define ZTNA tags or tag groups to enforce zero-trust, role-based access. You can configure security profiles to protect this traffic. You can also configure authentication to the access proxy. ZTNA supports basic HTTP and SAML methods. Zero Trust Access 7.2 Study Guide 117  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET After you add FortiClient EMS as the fabric connector and you sync ZTNA tags with FortiGate, you must create a ZTNA server or access proxy. The access proxy VIP is the FortiGate ZTNA gateway that clients make HTTPS connections to. The service and server mappings define the virtual host matching rules and the real server mappings of the HTTPS requests. The Servers table, allows you to configure the real server IP address, port number, and status. You can configure multiple servers and server mappings. By default, client certificate authentication is enabled on the access proxy policy and it blocks the traffic if the client certificate is empty. You can change the action using the CLI, if required. Zero Trust Access 7.2 Study Guide 118  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET A ZTNA rule is a proxy policy used to enforce access control. You can define ZTNA tags or tag groups to enforce zero-trust, role-based access. To create a rule, type a rule name, and add IP addresses and ZTNA tags or tag groups that are allowed or blocked access. You also select the ZTNA server as the destination. You can also apply security profiles to protect this traffic. Zero Trust Access 7.2 Study Guide 119  Configure ZTNA for Secure Application Access DO NOT REPRINT © FORTINET You can add authentication to the access proxy, which requires you to configure an authentication scheme and authentication rule on the FortiGate. You use authentication scheme