--- title: "Security" canonical: "https://docs.aryaka.com/space/KNOW/1210941743/Security" format: markdown --- Aryaka Unified SASE integrates networking and security to provide optimal performance in a flexible and cost-effective solution. Observe and manage your security service with the following MyAryaka pages: Monitor —Observe your network’s security activity over a selected time range. Drill into a security engine to view usage. NGFW —View and manage the Next-Generation Firewall rulesets that are shared by your sites. These rules enforce pre-ssl access control based on user-defined match criteria to determine if further inspection is required for web and DNS traffic. IPS —View and manage the IPS rulesets and the signature templates used by your sites. DNS Filtering —View and manage DNS Filtering rulesets that are shared by your sites. DNS filtering inspects DNS payloads and blocks requests based on user-defined match criteria including domain, reputation, and category. SWG —View and manage Secure Web Gateway rulesets that are shared by your sites. These rules enforce post-ssl access control based on user-defined match criteria to determine if further inspection is required for web traffic. CASB —View and manage CASB configurations such as sanctioned application classification, access control, and tenant restrictions. Data Loss Prevention —View and manage DLP configuration such as data types, data profiles, inspection objects, and rulesets. Anti-Malware —View and manage Anti-Malware rulesets shared across your sites. These rules determine whether malware detections are enforced or ignored during file transfers. Asset Management —View and manage shared collections, such as a group of IPs or domains, that can be reused in your security rules. Settings —View and manage zones, secure identity access portal, the blocking page, and other general security settings. This document describes each of the Aryaka network security offerings, provides an overview of the security rule framework, and outlines some best practices to consider when configuring your service. Network security offerings Aryaka currently offers the following security services: Firewall as a Service (FWaaS) Next Generation Firewall - Secure Web Gateway (NGFW-SWG) Anti-Malware Intrusion Protection System (IPS) Cloud Access Security Broker (CASB) Data Loss Prevention (DLP) Together, these six offerings provide the following controls on traffic: IP-, domain-, URL-, and file reputation-based flow filtering Identity signature-based filtering L3/L4 access control L7 access control Routing controls Basic firewall controls DNS filtering Anti-malware IPS CASB DLP The six security offerings are described in the sections that follow. FWaaS The Aryaka FWaaS offering is included with your site and remote user SD-WAN subscriptions. This service includes the following security engines: WAN Routing and Basic Firewall Internet Routing Interzone Firewall DOS Protection These security engines route or drop traffic according to user-defined security rules. The Aryaka FWaaS also includes the following capabilities: Dynamic application discovery—Identifies the applications in your network. Geolocation discovery—Identifies the source or destination country associated with network traffic. For more details about this service, including how to configure and monitor it, see the FWaaS topic NGFW-SWG The Aryaka NGFW-SWG offering is included with Unified SASE subscriptions. It allows you to enable the following security engines for your sites and private access nodes: DNS Filtering Next Generation Firewall Secure Web Gateway These security engines protect your sites and remote users by intercepting traffic and applying user-defined security controls to it. The Aryaka NGFW-SWG offering also includes the following functionality: Aryaka Identity Management—Identifies and controls network user access. Secure Identity Access Portal—Authenticates authorized users and blocks unauthorized users. Aryaka Secrets Manager—Generates dynamic server certificates and manages your certificate authority for SSL interception. For more details about this service, including how to configure and monitor it, see the NGFW-SWG topic. Anti-Malware The Aryaka Anti-Malware offering is included with Unified SASE subscriptions. It allows you to enable the Aryaka Anti-Malware security engine for your sites and private access nodes, which inspects network traffic for known malware, viruses, and file-based threats. The security engine classifies the files it inspects according to reputation (good, bad, or unknown) and permits or denies them according to your configured security rules. For more details about this service, including how to configure and monitor it, see the Anti-Malware topic. IPS The Aryaka IPS offering is included with Unified SASE subscriptions. It allows you to enable the following three Aryaka IPS security engines for your sites and private access nodes: WAN-Side Basic IPS—Inspects inbound traffic at the public-facing perimeter. LAN-Side Basic IPS—Inspects outbound traffic at the LAN perimeter. Advanced IPS—Determines if SSL inspection is required and inspects outbound traffic. These security engines identify potential security threats using signatures —unique patterns and identifiers from past security incidents. Each security engine that inspects the traffic generates a verdict on whether the traffic should be allowed, dropped, rejected, or logged and then permits or denies the traffic according to your configured security rules. For more details about this service, including how to configure and monitor it, see the IPS topic. CASB The Aryaka CASB offering is included in Aryaka’s Advanced Security subscription. When you add Advanced Security to your sites or private access nodes, you can enable the following two CASB security engines: SaaS Apps Access Control—Enforces security rules to control access to SaaS applications. Tenant Restriction—Enforces tenant restrictions by manipulating HTTP headers of SaaS application traffic. These security engines, in addition to the ability to classify sanctioned and unsanctioned SaaS applications for your organization, provide access control and tenant restriction for SaaS application traffic in your network. For more details about this service, including how to configure and monitor it, see the CASB topic. DLP The Aryaka DLP offering is included in Aryaka’s Advanced Security subscription. When you add Advanced Security to your sites or private access nodes, you can enable the DLP security engine, which enforces security rules to control the transfer of sensitive data. This security engine protects your organization from malicious and inadvertent data exposure. For more details about this service, including how to configure and monitor it, see the DLP topic. Security rule framework The network security component of Unified SASE is designed to allow you to achieve your organization’s security and routing requirements using simple workflows. By using multiple rule tables to support complex configurations and by leveraging reusable components, such as assets and rulesets , you can efficiently implement and scale your security configuration. This design also allows you to self manage or comanage your configuration as needed. Security engines Network traffic is inspected by a sequence of security engines based on your selected security offering. Security engines provide controls on user traffic, such as filtering based on IP, domain, URL, and file reputation. These security engines are depicted in the following graphics (first for outgoing flows, then for incoming flows): Engine sequencing for outgoing flows Engine sequencing for incoming flows When traffic flows and requests exit a site, they move from left to right through the sequence of security engines. To visualize the sequence of inspections performed on your traffic by the security engines, navigate to the Security > Monitor page of MyAryaka. For detailed information about the components of this page, see the Monitor security topic. Rule tables Each security engine has its own rule table that contains a collection of security rules. This multi-table approach allows you to maintain a high level of control over your security configuration without requiring you to manage a large and complex rule table. For example, if you want to block high risk domains at a site, you can modify the Domain Reputation rule table for that site without being concerned about rules in other tables. Each rule table can contain multiple user-defined security rules. When traffic encounters a rule table, the rules are evaluated in a top-down manner (that is from the first table row to the last table row) until a match is found for the traffic. If traffic matches a rule, the action associated with the rule is performed on the traffic. In general, the action can be to allow, drop, or log the traffic. If a match is not found, the next rule in the table is evaluated. Each rule table has a default rule at the bottom of the table that is evaluated last and matches all traffic. The following default rules are included in each rule table: Rule table Default rule DNS Filtering Traffic is permitted. Next Generation Firewall Traffic is allowed to bypass all subsequent processing. Secure Web Gateway Traffic is allowed to bypass all subsequent processing. Anti-Malware File reputations are not verified and traffic is permitted. LAN-Side Basic IPS Traffic is permitted. WAN-Side Basic IPS Traffic is permitted. Advanced IPS Traffic is permitted. SaaS Apps Access Control Traffic is permitted. Tenant Restriction Traffic is permitted and header manipulation is not performed. Data Loss Prevention Traffic is permitted. See the Configure site-level security features topic for an example of how to configure a security rule for an individual site. Rule match criteria Each rule table includes context-appropriate match criteria for traffic, such as source and destination IPs, users, source and destination ports, and domain names. When you configure a rule, you can select one or more match criteria to include in the rule and specify whether you want the criteria to be matched ( is ) or not matched ( is not ). Each type of match criteria you select can then include multiple entries. For example, most rule tables include Source IP as a possible match criteria. You can create a rule where the Source IP match criteria is defined as is (192.168.1.1/32 or 192.168.1.2/32) . Alternatively, you can create a rule where the Source IP match criteria is defined as is not (192.168.1.1/32 or 192.168.1.2/32) . When selecting match criteria, you can also select a predefined asset to be matched to traffic. For example, if you have an IP asset named non-threat-IPs, you can define the Source IP match criteria as is (192.168.1.1/32 or 192.168.1.2/32 or non-threat-IPs) . See the section on Assets for more information about using assets in your rules. Note the OR conditionals used in the previous example when making multiple selections within one match criteria type. The rule specifies that traffic can match any of the entries listed. However, different match criteria are treated as AND conditionals and traffic must match at least one entry from all selected match criteria to be considered a rule match. Consider the following example rule that is configured with multiple match criteria: source ip is (192.168.1.1/32 or 192.168.1.2/32 or non-threat-IPs) , destination port is 53 , and destination ip is 8.8.8.8/32 . To be considered a rule match, traffic needs to match one of the source IPs, match the destination port, and match the destination IP. The HTTP Header match criteria is an exception to the match any condition. You can specify if the condition to match a HTTP Header is Match Any or Match All as shown in the following graphic: See the Security rule match criteria topic for more information about the types of match criteria you can include in your rules. Rule actions Each rule table includes context-appropriate actions to execute on matched traffic. When you create a rule, you can select an action for the security engine to execute when traffic matches the criteria included in the rule. For example, the Next Generation Firewall rule table actions are PERMIT , DROP , LOG ONLY , SKIP ALL , REJECT , and PROHIBIT . Assets Assets are user-defined collections of a type of match criteria. After you create an asset, you can use it to match traffic in various rule tables. For example, you could define a Port asset with a list of ports and then use that asset in a security rule to permit or deny traffic when any of the included ports are the traffic source or destination. For more details about the types of match criteria you can create assets for, see the Security rule match criteria topic. To configure assets in MyAryaka, see the Asset management help topic. Rulesets Each site can have its own rule table if required. However, rulesets allow you to apply one or more security rules to multiple sites. Aryaka includes the following four ruleset types: Default —Each rule table includes a default ruleset that includes one or more rules that determine what happens to the traffic if you do not define any additional custom rules. This read-only ruleset is attached to all sites. You cannot edit this ruleset, but you can override it by writing one or more custom rules and placing them above the default ruleset (that is, assigning them a higher precedence). Global Non Overridable —Each rule table includes an empty Global Non Overridable ruleset. This ruleset is always attached to all sites—it cannot be detached or deleted. When you add a rule to this ruleset, it is fixed at the top of the rule table for every site and no configuration can override it. This ruleset allows you to create a single rule that is always honored by all sites. High Priority Custom —Each rule table can be configured to include a High Priority Custom ruleset as required. These rulesets can be applied to specific sites. This ruleset is located in a fixed position fixed below the Global Non Overridable ruleset’s rules and no other type of ruleset or site level rule can override it. Only one High Priority Custom ruleset can be attached to a site. This construct allows you to write configuration for different classes of sites, for examples, sites in a specific region can be given different configuration. Normal Priority Custom —Each rule table can be configured to include a Normal Priority Custom ruleset as required. One or more of these rulesets can be applied to a specific site. Rules included in this ruleset can be placed at any priority. It can be overridden by other Normal Priority Custom rulesets and by site-level rules. The evaluation order of a site’s rule table that contains each ruleset type and site-level rules is as follows: Global Non Overridable rules High priority custom rules Site-level rules Normal priority custom rules Site-level rules Default rules To view available security rulesets, log in to MyAryaka and navigate to Security . For detailed information about creating or editing a ruleset, see the Security engine rulesets topic. To view the selected site’s associated rule table and the rulesets attached to it, navigate to Sites > siteName > Security > View . For detailed information about site-level security rules, see the Configure site-level security features topic. See the Security engine rulesets topic for an example of how to configure a ruleset. Self-management and co-management The Aryaka security rule framework is designed to be self managed. Any user with write permission to MyAryaka can enable security engines and add or edit security rules without needing to contact Aryaka customer support. MyAryaka security configuration pages are located at Sites ( site-specific security configuration ) and Security ( rulesets and shared configuration ). Any of these configuration settings can be edited by a user and the Activate Now workflow applies the configuration to the network. For more information see Activate configuration updates . In addition to your ability to self manage your configuration, Aryaka can also manage your configuration. The following features help one or more administrators (whether it is you or Aryaka) manage your configuration: Save as Draft —Changes made in MyAryaka can be saved as a draft for review. This is useful when multiple administrators are involved in making changes and a review is required before submitting changes to the database and activating them on the network. Changes to each rule table can be saved as a draft. These changes are identified by an orange triangle next to the modified rule’s name. The modified components of the rule are also displayed in orange—you can hover over the change to view whether there was an addition or deletion. Cascading Assets —Aryaka maintains a master collection of assets that can be used for certain use cases, for example, an IP that Aryaka has determined to be safe despite the Webroot classification. These assets can be attached to a customer’s configuration so that it stays updated as Aryaka makes updates to its master assets. Any rule that uses this asset automatically receives a modified match criteria as the asset changes. These assets are identified by the label OWNED BY ARYAKA and are attached to a customer’s configuration after review with the customer and cannot be modified. The customer can opt out of this configuration when it is introduced or when alerted to future updates to the asset. Best practices Consider the following best practices when configuring security rules for your organization: Understand the needs of your organization. Create rules that fit your organization's requirements, compliance obligations, and risk tolerance. Configure zones. Use zones to segment your network and contain potential security breaches. Apply security rules to control the traffic between zones. Monitor security logs. Regularly monitor and audit the effectiveness of your security rules. Analyze your security logs to review traffic that has been blocked or that you have selected to monitor for any false positives. Then, create or update your rules as needed to optimize your organization’s security. Consider rule order. Ensure that the rules included in each rule table are in the proper order. In general, more specific rules should be placed above less specific rules, as rules tables are evaluated from top to bottom. For example, if a rule table contains eight rules and traffic matches rule #2, rules #3–8 are not evaluated and the rule action specified in rule #2 is executed. Use appropriate rule names. Use rule names that are simple and clear. For example, a rule that blocks social media websites could be named Block social media instead of the more general Block websites . Regularly review and update rules. Ensure that your rules are kept up to date based on your company’s current requirements. Delete rules that are no longer needed. Delete rules that are no longer needed to avoid cluttered rule tables. Disable rules only if they are not needed for a short period of time. Create rulesets. Use rulesets to apply a group of security rules to multiple sites. Create assets to use as match criteria. Use assets to create a named collection that can be reused as match criteria in your security rules. In this topic Related topics Getting Started with Aryaka Unified SASE Security engine rulesets Configure site-level security features