Objects Overview

Policy objects are resources used to define the match criteria referenced inside a policy rule. Traffic entering a gateway instance is then evaluated against this match criteria. Rules are the individual sequences inside the policy ruleset attached to a gateway or a set of gateway instances front-ended by load balancer. When traffic enters a gateway instance, each rule in the ruleset is evaluated against the incoming traffic in a strict order until a match is found, or the end of the ruleset is reached. For more information, see Rules.

What are these Objects for?

Need for Policy Objects

Objects play a crucial role in defining the type of traffic a particular rule is looking to match against and then take a specified action on. If traffic matches the object definitions referenced inside a particular Rule (AND logic for match), the matched traffic can be allowed or denied. If the traffic is allowed, additional advanced security profiles can be applied for further inspection. Each type of object helps define match criteria at a different layer of the OSI model.

Types of Policy Objects

Address Objects: Address objects are used to define match criteria that is mapped to Layer 3 IP addresses. These objects are referenced inside a policy rule. Address objects can be defined using explicit IP addresses/CIDRs, FQDNs, or cloud-native resources discovered by the Multicloud Defense Controller through periodic asset discovery / real-time event tracking.
Service Objects: Service objects are used to define Layer 4 match criteria that is referenced inside a policy rule. They are also used to define how a gateway instance will process an incoming traffic flow. This is referred to as the connection type.

For example, if the Service objects are defined with a connection type of either Forwarding or Forward Proxy. When the connection type is set to Forwarding inside a Service object, the incoming traffic flow is passed through the gateway instance. No proxying and/or decryption occurs. In this case, you can use the Service object to define a set of destination ports and the associated protocol incoming traffic will be evaluated against when a specific policy rule is processed.

When the connection type is set to Forward Proxy inside a Service object, the incoming traffic flow is proxied through the gateway instance. Decryption will occur depending on the proxy type. In this case, you can use the Service object to define the proxy type as well as the destination port or set of ports the gateway instance will be listening on for packets sent from the client. The gateway instance will specifically listen for a HTTP Request packet or a TLS client Hello. Once it receives this packet, the gateway instance extracts the host information and uses it to establish a separate connection to the external host.
FQDN Match Objects: FQDN Match Objects are used to define a set of FQDNs for explicit whitelisting or blacklisting. The gateway instance extracts the host information from a HTTP request or TLS client hello and uses it to match against the FQDNs listed in the FQDN Match Object. These FQDN Match Objects are evaluated against incoming traffic at Layer 5 and are particularly useful for matching against HTTP or HTTPS traffic, where host information is visible in the request packet.

Usage of Policy Objects

Once a policy object is defined, it is referenced inside a policy rule. It is important to note that although each of these objects can be referenced inside a policy rule, only Src/Dest Address Objects and Service Objects are mandatory objects when defining a rule. The FQDN Match Object is an optional parameter.

Matching traffic based on src/dest address objects, service objects and or FQDN match objects invokes the first two stages of the data path pipeline (L4 FW/FQDN Match) used to inspect traffic within each gateway instance. This is important to note because these stages are the first points of traffic inspection. The incoming traffic flow may be dropped at one of these stages or it may be allowed to pass through and be inspected at stages further along the pipeline correlating to the advanced security profiles referenced in the matched rule.

Static Objects

Static objects specifies unchanging IP addresses, subnets, or specific firewall rules to provide predictable and stable configurations which can be important for compliance and security purposes. In a cloud environment, this allows you to create and share objects that maintain the same IP address or FQDN within a hybrid environment.

If you choose to delete a shared object, Multicloud Defense deletes it only from its system. The object continues to exist within Security Cloud Control.

Dynamic Objects

In contrast, dynamic objects do not have to specify an IP address at all. Dynamic objects are adaptable configurations that automatically adjust to varying conditions or environments. They allow firewalls to respond to real-time events without requiring manual intervention.

You can also tag resources and use them as objects to create a more fine-tuned ruleset within your policy. This level of fleibiltity within a cloud environment allows the system to adjust for yoou based on real-time data and can result on reduced maintenance.

Sharing Objects with Security Cloud Control

In an environment where you may have cloud-based managers such as AWS or GCP interacting with on-premises datacenters, it is crucial to be able to share objects within policies to protect your environment. Shared objects make it easy to maintain policies because you can modify an object in one place and that change affects all other policies that use that object. Without shared objects, you would need to modify all the policies individually that require the same change.

Multicloud Defense shows you a combined or "flattened" view of the elements of the object in the details pane. Notice that in the details pane, the network elements are flattened into a simple list and not directly associated with a named object.

Note that sharing objects is only supported when you deploy an access control policy that allows traffic from your cloud-based datacenter. Ensure that your policy includes, or excludes, instances or attributes from your third-party datacenter.

When you share objects with Security Cloud Control they are automatically translated into network objects. This does not affect the original state of the object in Multicloud Defense.

To configure object sharing between Multicloud Defense and Security Cloud Control you must create a connector in Security Cloud Control and attach the connector to an applicable policy to enable this feature and then import objects to see them in the Multicloud Defense Controller. See About the Multicloud Defense Connector for more information.

If you happen to share dynamic objects there is the option to preserve the original values of the object by creating an override value. An object override allows you to override the value of a shared network object on specific devices. See Object Overrides for more information.

Note	Objects cannot be shared with Cloud-delivered Firewall Management Center.

Resource Tagging in Objects

In a traditional policy configuration, incoming traffic is matched against objects and profiles; these constructs often include stagnant IP addresses that must be manually and routinely updated. By including resource tags in your objects, you can avoid mismatches with incorrect or stale IP addresses by matching traffic against a fluid resource tag that is defined by its type, name, or value and not just an IP address or address range. Since tags are not dependent on the cloud service provider you are using, you can easily group and share the same tags or have multiple tags used in policies without incident.

As of now, Multicloud Defense supports resource tagging with the following inventory types:

Subnets
VPCs/VNets
Instances

Once you add a tag to an inventory item and attach a value you can add it directly to your policy or even build a policy around the tags you have created. See How to Tag Object Resources for more information.