Policy creation in Akamai Guardicore Segmentation follows a set rules that are described in

this module. Understanding the structure, and the matching order is critical in implementing an
effective segmentation policy.
In this module you learn how rules a created, and how they applied to agents and secure
DNS.
In this Lesson, you discuss the rules creation process and matching logic as well as
rule hit counter.
Go over the objectives of the Policy rules lesson
There are six rules as indicated. In addition, there are also implied rules which are not displayed
but have a higher level of priority and therefore are applied before any other rules, even
override rules. Standard Allow, Alert and Block rules should be used as much as possible and if
there is a need to block something before it meets an Allow rule, you may need to raise the
Block to a higher priority than Allow by using Override block. The Override option therefore
raises the rule priority.
This flow chart describes the packet journey against the configured rules. Alert and Block actions have
the following actions:
● Alert: Allow the traffic but only generate an incident if the “ trigger an incident report following
an Alert rule” is checked as shown under SystemConfigurationIncidents.
● If the action selected in a block rule is “Block and Alert” the traffic will be blocked but only
generate an incident if the “ trigger an incident report following an Alert rule” is checked as
shown under SystemConfigurationIncidents.
If the traffic matches no rule, it will be allowed by default.

This is a connection journey:

Does not matter incoming / outgoing connection;
First, we check if there is a match against an Override allow rule, if there is – allow the traffic. If there
is not, check if there is a match against an Override alert rule. If there is, allow the traffic and may
generate a policy violation incident if it is triggered as explained earlier.
If there is no match against Override allow or override alert, check if there is a match against override
block rule. If there is, block the traffic. For Block, we also have “Block and Alert” that blocks the traffic
and may generate policy violation incident if it is triggered as explained earlier.
Because sometimes you want the traffic to be blocked as well as sending an incident to your SOC
team.
Now, we do the same thing all over again using standard allow alert and block rules.
If there is no match against override block, check if there is a match against standard allow rule. If
there is a match, allow the connection, if there is no match – check if there is a match against an alert
rule. If there is a match, allow the connection and may generate a policy violation incident.
If there is no match against an alert rule, check if there is a match against a block rule (or block and
alert) if there is, block the traffic, (if it is block and alert – also may generate and incident as well). If
there is no match against any of the rules, by default allow the connection.
Allowing the connection by default is set by implicit rules on the agent side that will be discussed in
next lessons.
Label Groups - A rule with a single label group as source or destination is matched on any asset
that belongs to one of the labels within the label group and doesn't belong to the excluded
labels.

Labels - A rule with a label as a source or destination is matched on any asset or IP address
that belongs to the selected label. Multiple label selection is supported. You can create OR
criteria for a label by selecting several labels from the dropdown list. You can create AND
criteria for a label by selecting several labels from the list and adding them using the ‘&’ sign.

Labels groups are used when you want to include a series of application and exclude some
app.
Labels should be used instead of assets as source or destination since labels can cover more
assets.
When an asset is repurposed or provisioned on a different platform the policy attached to it will
still be applied
There is a difference between AND (&) and an OR when we choose labels.
OR condition is between each line. E.g. “Production” OR “Accounting” OR “Load Balancers” -
will include All “Production” assets or All “Accounting” assets or All “Load Balancers” Servers,
which is not equivalent to the 4th row.
The 4th row has “Production & Accounting & LB” which only include the assets that have all
those 3 labels. This is an intersect as the image shows.
Left image shows intersect between “Accounting and Load Balancers” and middle image has
intersect between “Production and Accounting”.
The outcome of the selection of “Accounting & LB” OR “Prod & Accounting” in the right side
image.
An application is a process on which to apply the policy. The use of processes gives a level of
granularity allowing to drill down to the individual service. A rule with a process as
source/destination will match any traffic from/to this process on any agent.
Processes can be set for either full-path matching which will match the execution of the
process based on the specified directory where it is located, or all-path which will match the
execution regardless of where the process is run.
In a Block rule, Guardicore doesn’t support a rule with a process as both source and
destination.
Starting with v48, the default behavior of displaying processes with Full path can be changed to
all path by unchecking the option as shown.
A rule with a source / destination that only contains a process will only be derived to source /
destination agents. Affected rules will show an Orange dot indicating this special behavior. For
example, an “alert telnet.exe → ANY" rule will only be derived to source agents with an “alert"
action. Destination agents will not explicitly allow any incoming traffic due to this rule. This
ensures that alert and block rules behave consistently.
Users can configure Service Level Policy and include Windows services as the source /
destination of policies (like processes) and create rules blocking / allowing flows to / from
Windows services. This feature will enable setting up multiple services per rule, as well as
creating rules that allow or block traffic to or from “only services” using the Any service option
in rule creation.
FQDN (Fully Qualified Domain Name) is only used as Destination in a rule. It is matched against
all the domain’s IP addresses.
With domain-based rules you can create policies that allow access to a specific domain by its
domain name rather than its IP(s).
Only Allow Rules are supported and FQDN avoids having to manually list all the domain’s IP
addresses, saving time and hassle of collecting all the possible IPs. Block rules for FQDN are
not supported and can be achieved by configuring DNS security (discussed later).
User Groups (Source field only) - You can create Allow rules whose Source field is restricted to
specific User groups.
The User groups are derived from groups in the Active Directory. This enables creating more
fine-tuned rules that depend on the users initiating a communication flow. To add a User Group
to a Source, you must first select a Label Group, Label, Asset or a Subnet.
Source must be a Windows server with an Agent installed. To activate this feature, you must
first configure Orchestration to the Active Directory and to create a User Group. On the
Operating System Level, the agent queries the OS and matches if the origin user is part of the
Active directory groups SID.
The slide demonstrates how a user group can be created using active directory groups. You
may not see active directory groups listed here if an Active Directory orchestration has not
been successfully run.
Once the user group is created, it can be used in segmentation rule creation.
In the right side of the slide, you may see an image with 3 rules.

1. If traffic is originated from the Jumpbox and the user group is HRM, allow the HRM
App users to reach HRM App in Production
2. If traffic is originated from the Jumpbox and the user group is Billing, Allow the
Billing App users to reach Billing App in Production
3. Block any other connection attempts from the Jumpbox to Production. This will
ensure that HRM App users and Billing App users will be able to access only to their
own application and not each other application.

For additional information, access the following links:

https://techdocs.akamai.com/segmentation-v50/docs/policy-rules
https://techdocs.akamai.com/segmentation-v50/docs/policy-rules-screen#creating-policy-
rules
You can narrow the scope of a rule by specifying the protocol (TCP, UDP, ICMP) and ports (e.g.
TCP port 80).

You can also specify a combination of protocols and ports, and you may specify exclusion of a
combination of protocols and ports.

Note: on Windows machines, if there's an explicit block rule of ICMP in Windows Firewall, it will
overwrite Akamai's verdict regardless of the Guardicore Windows Interoperability mode.
The action that will be taken once the traffic flow is matched to the rule.

 Allow and Override Allow rules support the Allow action.

 Alert and Override Alert rules support the Alert action.

 Block and Override Block rules support either a Block or a Block and Alert action.

The Override Allow, Override Alert, and Override Block sections can only display an Allow, Alert,
or Block action.
For ease of exploration and local association of a rule with its purpose, the Ruleset column
enables you to group segmentation rules according to ruleset names.

When publishing policy, the publish can be limited to specific ruleset only.

To create a ruleset name, simply click in the ruleset column next to the rule that you want to
assign to the ruleset and type a name for the ruleset.
You can filter rules by their ruleset by using the Ruleset filter at the top of the screen.
To assign multiple rules at once to a ruleset, filter the list of rules until you display the rules to
be assigned to the ruleset, then click the Bulk Operations button,
select the Move Ruleset option and specify the ruleset to which you want to move the rules. All
the rules displayed on the screen will be moved to the specified ruleset.Ruleset enables
consolidation of segmentation rules based on names.
While you create/edit a rule, and choose any of the shown tabs [processes, assets etc.,] if you
switch to another tab before clicking apply - you will be prompted whether to reset your choice
and move to the clicked tab, or if it accidently clicked, to stay in the current tab by click
Dismiss.

Changing a rule parameter prompts a switching tab which draws awareness about whether
the action is intentional (in which you switch) or accidental.( in which you select dismiss).
Will be blocked: When the agent has the enforcement module operating mode set in
monitoring mode, it cannot enforce policy. if there is a policy rule with block action, it will not be
able to enforce it so the agent will be blocking only after the operating mode change to
enforcing.

Could not block: When there is a verdict mismatch between the management server ( Block)
and the agent ( allow), the agent could not block.usually due to the agent not receiving the
policy from the management because of network issues,etc.. So it is important to look at the
logs to drill down to the root cause
Akamai Guardicore Segmentation enables full IPV6 support as follows:

 IPv6 flows are clearly visible on the Reveal map

 You can create enforcement policies over IPv6 traffic
Limitations to IPv6 support are:

 No support for Windows 2003, AIX, Solaris, and HP-UX.

 No support for 4in6 enforcement.

To avoid blocking any IPv6 traffic, 0.0.0.0/0 (quad zero) can be used instead of Any, this will
only match IPv4 traffic.
Guardicore Rule Hit Counter displays the number of times a rule is matched to an observed
connection, enabling you to keep track of the number of times a rule is used.

Hit Count allows us to Identify unused Allow rules and Identify triggered Alert / Block rules as
well as view metrics of North-South and East-West connections rates within environments,
applications, etc. The counter refresh rate is up to 5 minutes.

Ultimately, the feature can be used as a way to test a rule’s efficiency. Specifically, for rules
with no hit for a long period of time, such rules need to be reformulated.
In order to enable Rule Hit Count calculation, access the System menu category and select
Configuration. Then, under General, make sure that “Show policy rule hit count” is checked.
A demonstration in Guardicore is in order here to show how the rule hit counter can be set so it
show in the policy rules screen.
Rule Hit counter records the number of times the rule was activated. The column “Hits”
displays in the following units:
0, 1-1K, 1k-10K, 10k-100K, 100K and more.
The bar appearing next to the number of hits provides a graphic description of the number.
Hovering over the hit number displays a notification of the exact number of hits, as well as
when the hit counter was last reset.
Now we can clean and harden policies with The “Last hit”. Other options available are:
 ‘N/A’ – No information available about when the rule had the last hit
 ‘X days ago,’ - The last hit will be presented in days and not in timestamps
 ‘Today’ - in case there was at least one hit today for this rule
Resetting the hit count also resets the last hit.
Rule Hit Counter also enables you to evaluate the efficacy of your rules and revise your policy.
For example, you may want to eliminate rules that have limited or no usage or revise them so
that they are more effective.
By hovering on a hit count you get a better understanding of the number of hits, the last hit, and
the last reset. So you can decide whether to remove or reformulate based on the hit count.
The Rule hit counter can be filtered based on the number of hits as indicated above. It
enables users to filter rules according to their usage. The filter uses the same
calibration units as the Hits column.
Resetting the Hit Counter for a particular rule can be done by selecting the menu button at the
left of the rule and clicking the Reset Hit Counter option.
Users can also reset the hit counter when reverting to an older policy revision. Rule Hit Counter
max number is 2^63 which is a very long number. There is no auto reset. Once the limit is
reached, there is no more counting.
It is also possible to reset the Hit counter for all the rules listed on the Rules screen by filtering
or selecting relevant rules and drilling down using the Bulk operations button and choosing
Reset Hit Counter.