Copyright© 2024, Opinnate, Inc. All rights reserved. No part of this document may be reproduced, translated into another language or format, or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Opinnate, Inc.

8, 320 Tubbenden Lane South,

Bromley, BR6 7DN, United Kingdom

Trademarks Opinnate®, the Opinnate logo and the names and marks associated with Opinnate products are trademarks and/or service marks of Opinnate, Inc. and are registered and/or common law marks in the United Kingdom and various other countries.

All other trademarks are property of their respective owners. No portion hereof may be reproduced or transmitted in any form or by any means, for any purpose other than the recipient’s personal use, without the express written permission of Opinnate.

End User License Agreement By installing, copying, or otherwise using this product, you acknowledge that you have read, understand, and agree to be bound by the terms and conditions of the End User License Agreement for this product. The EULA for this product is available on the Opinnate Support page for the product.

Disclaimer While Opinnate uses reasonable efforts to include accurate and up-to-date information in this document, Opinnate makes no warranties or representations as to its accuracy. Opinnate assumes no liability or responsibility for any typographical or other errors or omissions in the content of this document.

Limitation of Liability Opinnate and/or its respective suppliers make no representations about the suitability of the information contained in this document for any purpose. Information is provided “as is” without warranty of any kind and is subject to change without notice. The entire risk arising out of its use remains with the recipient. In no event shall Opinnate and/or its respective suppliers be liable for any direct, consequential, incidental, special, punitive or other damages whatsoever (including without limitation, damages for loss of business profits, business interruption, or loss of business information), even if Opinnate has been advised of the possibility of such damages.

Customer Feedback We are striving to improve our documentation quality and we appreciate your feedback. Email your opinions and comments to [email protected]. Visit the Opinnate Support Center for End User License Agreements, software downloads, product documents, product licenses, troubleshooting tips, service requests, and more.

1        Introduction #

This document is the user guide for Opinnate Network Security Policy Manager for the version 4.1.0.

It is recommended that you read this instruction manual carefully before use.

This product is suggested being used on a server with the mentioned Operating System and version:

• Ubuntu v18 or higher
• Docker Engine installed
• Docker compose installed

The use of any other OS is not supported.

Please, carefully read the precautions with  symbols, to ensure that the system is used in best conditions and in complete safety.

1.1        Conventions #

To avoid all configurational misconceptions, this document splits informational instructions into two levels.

	ATTENTION
	Care must be taken for this condition

	WARNING
	It may be serious issue if not done accordingly

1.2        Intended use #

This software is an aid for security operations. The operations that need hard and repetitive work activity is to be handled by this software. These activities may be firewall policy analysis, making policy changes and generation of specific reports.

Opinnate is a system that makes policy management easier with the capabilities identified in this document. In the first part the installation of the system, and alternative ways of this installation be given. The next part will be an overview of how the product works, what are its abilities, how it is licensed and what kind of packages exist. Also, the global configuration of the system will be detailed.

2        Installation #

The system is working in a containerized model so that you can use your system OS as per your needs. Before installation of the system please make sure that the requested Ubuntu based OS is prepared on the server and the system has the specified resources available. Also, docker engine and docker compose must be installed.

Prerequisites:

Docker engine installation : https://docs.docker.com/engine/install/ubuntu/

Docker compose installation : https://docs.docker.com/compose/install/linux/#install-using-the-repository

Main installation:

You’ll receive a compressed file containing:

• several .tar files that are containing Opinnate Docker images,
• a docker-compose.yml file,
• run.sh file that is a bash script to load the Docker images and run the compose file.

Extract the contents of the compressed file, preferably to /srv/opinnate directory.

Execute the bash script with sudo privileges.

• sudo bash run.sh
• Script will import the docker images and run docker-compose file.

Access Opinnate application in https://localhost:443 or in https://<ip of the device that the app is running on>:443 from any other machine.

When connected a license page will be seen, now you will need to copy the system ID from this page and share this information with your partner. After this step the license file purchased be needed will be generated to be able to connect to the system.

Once you have the license upload the license file using the Upload License file button and now the system is ready.

Please note that the installation guidance in this document is brief, for detailed instructions you can check the Installation Guide.

3        Getting started #

The system is composed of two main areas. The first area is the global area where all general settings and user settings are configured. The other area is the virtual area where all firewall policies are managed. These virtual areas are used for multitenancy purposes and each virtual area is separated from the others and can be managed with different authorization levels.

Opinnate is licensed in three different editions as follows:

• Lite
• Standard
• Enterprise

Lite	Standard	Enterprise
Analysis	Analysis	Analysis
Audit	Audit	Audit
Reporting	Reporting	Reporting
	Optimization	Optimization
		Automation

As seen in the comparison chart, the Lite edition is the basic model and the mentioned features exist, so for this licensing model just the related functions be used.

Following are the explanations of each function and their purpose:

Analysis:

Analysis is related to making detailed analysis of firewall rules. The system will be giving information about unused rules, duplicated rules, shadowed rules, etc.

Audit:

In the audit part system will be generating reports for compliance purposes. The compliance reports that can be generated from the system are ISO27001, PCI-DSS, NIST, SOX, HIPAA, GDPR, SWIFT, DTO and BRSA.

Reporting:

Both for compliance purposes and special needs a limitless number of reports can be generated from the system. For example, all permissive rules on all the firewalls.

Optimization:

Analysis results cannot be automatically implemented, or hardening must be done manually if optimization module is not in place. For example, disabling all the expired rules automatically is possible with this feature.

Automation:

Policy changes on firewalls be done automatically with this feature adapting the necessary routines like approval in place.

3.1        Connecting to the System #

When connected to the system the first screen to be displayed will be the global dashboard. On the global dashboard license information, logged in admins, system information and virtual areas can be seen.

License:

In the license field apart from the model information the number of virtual areas and the number of firewalls can be seen. The system comes with one virtual area so, if there is a segmentation need or there is a different organization to manage additional virtual area license must be purchased. Firewall system number is the basic licensing data to be used no matter if the firewall is in cluster, physical or virtual the total number of firewall systems licensed be seen.

Logged in Admins:

During normal operation the users doing activity on the system can be seen in this area.

Virtual Areas:

The virtual areas activated on the system can be seen here with the information about how many numbers of firewalls exist in that virtual area.,

Apart from these fields, for the sake of easiness the addition of a new admin account and new virtual area can be initiated from this page.

From this point on other pages on the global area will be detailed starting from Admin Settings panel.

3.2        Admin Settings #

There are three menus in this panel: Admin Users, Admin Profiles and Remote authentication.

Admin Users:

In this page an admin user can be created on four different authorization levels by default. These are Super-user, Infosec, Firewall, read-only admin users. By default, an admin user exist which can be deleted once a new super-user added to the admin users. *

	WARNING
	It is strongly recommended to delete default username when the new super-admin user is created.

Admin Profiles:

All the fields and pages are categorized according to authorization levels. By default, four different profiles are already added to the system and these are cannot be modified. However, new profiles can be created and edited if it is needed or preferred.

Following is the super-user admin profile settings on the admin profiles page:

Similarly other profiles may be seen here on this page. Since default admin profiles are not editable so are their names.

Remote Authentication:

LDAP and Radius authentication methods are supported. Related authentication servers can be added for admin authentication.

Sample LDAP configuration settings is as follows:

3.3        System Settings #

General settings for the whole system are configured in this menu. There are five different pages to be seen on this page.

System Configuration: One can get the configuration backup of the system from here. Upgrading of the system and uploading of the backup file is also managed here.

Syslog: As the name implies syslog servers to which system logs be sent will be configured on this page.

Collector: The Collector module of Opinnate which is working as a standalone Linux server is added and managed from here.

Helpdesk: Helpdesk integration can be made using this menu. For the end users to create a new firewall service request there are three methods to use. These are Customer helpdesk, Opindesk (add-on Opinnate ticketing software) and Opinnate itself.

Settings: Ticket naming standard, idle timeout and period the system will be renewing data from the firewalls would be configured here. Apart from this password policy for local authentication can also be activated and configured here.

Logs & Debugging: All system global area logs be seen in detail. Debugging is used for the purpose of downloading error logs for support cases.

Licensing: System licenses be seen, and new license be added from here.

Certificates: If LDAPS authentication is needed, then there will be a certificate needed and the certificate to be used can be imported here.

3.4        Virtual Areas #

Virtual area naming and scheduling can be configured from here. Also, from here first-time data renewal is made.

3.4.1       Install Scheduler #

If it is required that there will be no action place during working hours then this schedule section can be used. If configured all tasks created on Virtual Area section will be in Waiting status till the configured time.

3.5        Switch Virtual Area #

Using this switch button, it is possible to go to virtual area section or from there back to global area section. This button will be either on the left bar menu or at the bottom of the middle menu.

3.6        Notification #

All actions going on the system can be followed using this left bar menu. All notifications seen will be collected here.

4        Virtual Area Operations #

From global dashboard one can go to virtual area dashboard on the left bottom panel of the UI. There are several menus to be used for the management of the system in virtual area section. The first screen to be shown is the virtual area dashboard. Here there are several widgets showing the overall status of the environment. Similar widgets can also be viewed on the firewall dashboard of each firewall for the analysis of that firewall. The widgets and the given information is as following:

Firewalls: Number of firewalls added to the system is shown. There are also other devices like switches and routers, and they can be seen from the devices menu or by clicking on this card.

Rules: Number of rules existing on the firewalls added to the system. These rules can be seen in detail from the rule viewer and by clicking on this card.

Shadowed Rules: Number of shadowed rules can be found on this card. Shadowed rules are the rules that are not processed because there is another rule above these rules in the policy table. No matter if the policy is a permit or deny policy the shadowed rules will be found and shown in the rule viewer for detailed analysis. In shadow analysis every criterion that may lead the rule below not to be looked upon is considered. Source IP, Destination IP, Service, Users, Application, URL Filter (If applied), IPSEC (If applied), Policy Target (If exists)

Expired Rules: Number of expired rules can be found on this card. Expired rules are the rules that are non-functional since the validity period has passed. Expired rules must be eliminated from the policy table since they increase the complexity level of it. All expired rules will be found and shown in the rule viewer for detailed analysis.

Disabled Rules: Number of disabled rules can be found on this card. Disabled rules are the rules that are non-functional since they are disabled. Disabled rules must be cleared from the policy table since they increase the complexity level of it. In routine operations these are the first rules that will be acted on because other rules to be optimized are to be disabled.

Policy Conflict: Number of rules that are not compliant to the corporate security policy. These are the rules to be reviewed first because of this incompliance. If the rules are necessary to use, then changes to the corporate security policy must be thought up and documented accordingly. Rules that are not compliant with the security policy can be analyzed from the rule viewer and corporate security policy table.  

Log Disabled: Number of rules for which logging not activated is shown. Logging is one of the crucial things in cyber security, so every single rule must generate log messages when there is traffic related to it. It is also a necessity according to several compliances. Detailed information and related rules can be found in rule viewer.

Risky Rules: Number of rules opening ports on risky services is shown. Risky ports are identified from best practices and from compliances and rules are found according to this port information. Detailed information and related rules can be found in rule viewer.

Opinnate uses the following services most of which are coming from NIST framework as risky services:

TCP:135/137-139

UDP:135/137-139

UDP:69

UDP:514

UDP:161-162

TCP:6660-6669

TCP:20-21

TCP:22

TCP:80

TCP:1433

TCP:23

TCP:445

TCP:1521

TCP:87

Tcp:79

TCP:0-19

UDP:0-19

UDP:23

TCP:3389

UDP:3544

TCP:5900

TCP:3306

TCP:5432

TCP:53

UDP:53

TCP:389

UDP:389

TCP:49152-65535

UDP:49152-65535

Permissive Rules: Permissive rules are the rules having permissive source or destination IP or permissive service containing high amounts of ports in it. The number of permissive rules can be seen here in four different levels: critical, high, medium, and low. The details of these rules can be found in rule viewer and can be analyzed further to find out which IP addresses are using it.

Each permissive level is described as below:

Critical: Rule having “any” in any field,

High: Rules having (src_count + dst_count)> 4096 or port_count > 20

Medium: Rules having (src_count + dst_count)> 512 or port_count > 10

Low: Other rules

No Hit Rules: The number of rules having no hit value on it; however, they may not be unused rules if they are newly added rules. So, for optimization purposes the creation date of these rules must also be known to decide if these rules are unused rules or not. Details of these rules can be seen via rule viewer.

Average Risk Score: Risk score of each firewall is calculated based on the following best practices: permissive rules usage, logging activation per rule, risky service usage, perimeter access, cluster, unused rules, corporate policy mismatch and IPS usage.

Here is the list of criteria considered for calculations:

Permissive rules

Risky rules

Rules that are not logged

Explicit rules existence

Perimeter rules

Clustering condition

Unused rules

Conflicting rules

Rules IPS not activated

Each criterion is calculated based on a risk level considering the rules and the total number of rules. Risk score is calculated based on the general formula below:

riskScore = 100-100*(1-calculatedRisk/totalRisk)

Apart from these number cards, it is also possible to add custom widgets using the Rules filter area by saving a filter. Also, there are several widgets showing information about active tickets on the system, the latest tickets created, firewall devices and their related statistics, etc.

4.1        Settings #

Settings is the panel that is used for integration of the system to the environment. Till this integration to be done all the fields on the main dashboard will be empty.

There are following menus and sub-menus on this part:

4.1.1       Device Integration #

Devices is the section where the necessary devices to be integrated. This integration is to be done on the Device Add/Remove menu. Here with the supplied necessary information the system will start connecting to the related device. The supplied information will be as follows:

Device Name: A unique device name for identification of the device. It is suggested to use hostname for the sake of standardization.

Device IP: Ip address to be used to connect to this device. *

Device port: Port number to be used to connect to this device. *

User profile: The user profile that is configured on the device user profile page to be used for different devices if they are using the same user and password information. *

	ATTENTION
	Be sure the necessary user creation and permit rules activation on the devices done previously. The communication with firewall devices will be on API and for the switches it will be on SSH.

Virtual firewall: If the firewall is a virtual firewall, then it must be defined accordingly.

Vendor: The vendor of the device be chosen from the drop down

Internet Firewall: If the added firewall is an internet firewall it must be enabled.

Cluster: If the added firewall is cluster, then it must be enabled.

To remove a device that is already added to the system flip menu be chosen on the upper section. The device to be removed be chosen from this list and from that point on the device and its related data will be removed from the system.

When the devices are added and integrated to the system, they will start to be seen on the Devices menu. From here if the connection is successful a check icon is seen near the related device. Using the Edit button, the configuration parameters of the related device can be updated. Using the Home icon near each device it is possible to reach device dashboard of each device to see the analysis data specifically for that device. Apart from the analysis data the interfaces and routing information on the device can be seen.

Device Add Wizard: It is also possible to add devices via Wizard. Here step by step workflow to inform the user what settings to apply after adding the user profile. In the first step device type is to be chosen from the list of devices such as Panorama, Forti Manager, FortiGate, Palo Alto, Check Point. In the second step necessary user information is given and in the last step settings such as IPS profile to be used can be chosen from among the configured ones on the firewall.

Device User Profiles: All the user profiles created can be listed and viewed here.

WARNING

For Palo Alto firewalls if Panorama integration exists, the only integration method must be over Panorama. Direct integration with firewalls will not work as expected.

LDAP Integration: LDAP Integration is the area that makes it possible to apply policy changes based on user information. From here the LDAP servers that exist in the environment will be added.

There are the following fields to be supplied for this integration in LDAP Server settings:

Domain name

Server IP

Server Port

Distinguished Name

User DN

User Password

Device&Domain Relation: Once the LDAP servers are integrated to the system the devices that have user integration with related LDAP server must be configured. With this information on which devices the domain integration exists will be known.

Other Devices: Devices other than the integrated ones can be seen on this menu. The interfaces and the routing are the data to be seen on the related device.

Certificates: For LDAPS communication there should be a valid domain certificate, and it is uploaded using this menu.

Sample LDAP configuration settings is as follows:

4.1.2       Environmental Settings #

Customer specific information be needed for audit and analysis. *

DNS Servers: Corporate DNS servers to be defined here.

PCI-DSS networks: Cardholder data network subnets to be defined here.

GDPR Networks: GDPR related servers or networks to be defined here.

PHI Networks: HIPAA related servers or networks to be defined here.

SWIFT Networks: Swift servers or networks be defined here.

Risky Analysis Ports: Apart from the list of risky services given in the previous section custom services can be added as risky to the list here.

WARNING

Related audit reports will not be generated as expected if these values are not configured correctly.

4.1.3       Alert and Notification Settings #

The system will be sending alerts when there are specific conditions aroused. For these alerts to be sent, necessary email integration must be done.

The SMTP Server Settings to be configured are the following: *

SMTP Server Status

Security Mode

Authentication

SMTP Server

Port

Username

Password

Sender mail

Sender Mail Title

It is also possible to use Auto configuration option for the related settings to be automatically tested with the server side and selected accordingly.

	ATTENTION
	Be sure to make a test when configuration is finished.

For automation workflows, Approve Notification and Operation notification users must be identified for the system to inform them when there is a new request.

Following are custom body field configuration menus for the related notifications.

Rules About to Expire Management: For rules that are about to expire a notification process exists. From here an email alert is sent to the rule owner.

Rule Lifecycle Management (RLM): For rules that should be reviewed if the need still exists RLM process can be activated for Opinnate to send notifications to the rule owners each year based on the creation time of the rule.

Status of Device Connection: If the connection between the firewall and manager is lost an alert is to be sent to the related owner.

4.1.4       Logs #

Logs related to the virtual area will be found here locally. From here detailed filters can be applied and search can be made effectively. Fields can be applied to are as follows:

Log Type

Log Time

Operation Type

From

To

Once the necessary logs are found they can also be exported to the local PC/Server in PDF or Excel.

4.1.5       Corporate Policy #

In this part of the system the corporate policy of the company can be imported and make it a visual one. The reason for this menu is to create firewall rules that are compatible with corporate security policy. To import policy the first thing to do is to define zones or network roles. After this, using the security policy matrix the inter communication between each zone is configured.

4.1.5.1      Network Roles #

Network roles are to be added in this part. Network role means a group of servers having the same duty or used for the same or similar purposes. It may not be the same on the network and it is not the same as network segments. To add a new role, Add New Role button be used to add the information needed to create the rule. The following are the fields to be needed for this creation.

Role Name: Name of the role that is being created.

Description: Explanation of this role but it is not mandatory

Negate: Excludes the IP address/es given

New IP: The IP address/es added to this group

4.1.5.2      Security Policy #

With the addition of the roles in the environment. They will be populated on Security Policy matrix that exist on this section. The relationship between each role can easily be configured on this matrix. With the information on this security policy each new rule to be created will be compared to it to make corporate security policy check. The matrix to be seen on this section will be like the following:

Between each role there is a settings button to be used for defining if the role can reach to the other role on any ports, certain ports or it must not reach the other role. The situation for allowance be shown via tick, block signs as seen on the picture. For reaching or not reaching on certain ports “i” icon be used. To see the details of this information, settings button is to be used.

5        Analysis Features – Lite, Standard, Enterprise #

Analysis is the activity of collecting firewall policies from all the firewalls and making thorough analysis of firewall rules. After this analysis is made the analysis dashboard cards are filled with the related values and the firewall topology is created. There are five main menus on this part:

5.1.1       Viewer #

All information that is collected from the firewalls such as rules, objects and NAT rules can be found here

5.1.1.1      Rules #

Rules is the part of the system where detailed searches on all the rules existing on the firewalls are made. After integrating the firewalls to the system, the policies start to be collected from all the firewalls and analysis process starts. Rules can be viewed with most of the commonly used parameters like Device Vendor, Source IP, etc.

There is a filtering area just above the Rules section. By enabling filter option one can make detailed search on rules.

The filtering area is as follows:

From here by choosing the necessary searched item in the related drop-down menu rules be filtered. These search fields can be combined in group wise or inter-group wise to use OR and AND operators in needed combinations.

Field Name: In the field name there are several parameters to be chosen like Source, Destination, Service, Comment, Device Vendor, etc.

Criteria: The criteria may have fields like “contains” for text values, “greater than” for numerical or date values and conditions to be checked as True or False.

Value: For this field the related text, number or date value be given as the search value

There are several fields that can be used for filtering. These are:

Action

Anti Spyware

App Profile

Application

AV Profile

Certification

Comment

Data Filtering

Destination IP

Destination Name

Destination Role

Device IP

Device Name

Device Type

Disabled

DNS Profile

Expired

File Blocking

First Create

From

HIP Profile

Hit Count

Inline Layer

Internet Service

IP Pool

IPS Profile

Last Modifier

Last Modify Time

Last Used

Layer

Location

Logging

Name

NAT

Permissiveness

Policy Match

Policy Package

Profile Group

Risky

Rule ID

Rule Owner

Schedule

Schedule Name

Security Profile Group

Service Name

Service Port

Service Protocol

Shadowed

Source IP

Source Name

Source Role

SSL Profile

To

URL Category

URL Filtering

Users

Virtual Firewall Name

VPN

Vulnerability Protection

Web Filter

Wildfire Analysis

5.1.1.1.1     Rule History View #

It is possible to see all modifications to a rule up to six months before the button on each rule card can be used. Once selected, a new page will be displayed as shown and show all modifications that happened for that rule.

5.1.1.1.2     Rule&Object Usage #

It is possible to see rule usage for any rule for the last one month. To see the related usage for that rule, a statistics button on each rule can be used. Once selected, a pop-up screen will be displayed as shown and by selecting rule usage or object usage option and selecting the starting period, the analysis will be made immediately without waiting for any monitoring period. The results for rule usage will be seen on Rule Usage Task List menu that will be detailed later. For object usage, the usage values should be displayed on a new pop-up screen, showing the usage percentage for each object included in the rule.

5.1.1.1.3     Rule Card Customization #

It is possible to choose which fields are to be listed on rule viewer for each vendor. To do that 3-dotted icon used on the upper right side of the rule viewer.

5.1.1.1.4     Risk Acceptance #

It is possible with Opinnate accepting the risk associated with a Risky, Permissive Critical or Policy Conflict rule. So, with this setting related rules start not to be listed as risky, critical or conflict to be able to effectively manage risks associated with the rules. These rules will be seen as Accepted till there is a modification that can affect the rule condition such as adding new service. In that case, rule will start to be shown as Accepted Modified

5.1.1.1.5     Rule Export #

The rules listed on the screen can be exported as pdf or excel file to analyze them offline.

5.1.1.1.6     Rule Edit (Automation Feature) #

It is possible to disable, enable a rule or update its fields like source, destination, or comment. This feature comes with Enterprise edition. If there is, one can easily select the necessary, rule/s to update easily via approval in place.

The following are the actions that can be taken on the related rules:

Disable Rule: To disable the selected rule or rules

Enable Rule: To enable the selected rule or rules

Delete Rule: To delete the selected rule or rules

Rule Reorder: To change the order of a rule. The order alternatives can be top, bottom or above or below of a selected rule

Rule Copy: To copy up to a maximum of 20 rules for one workflow from one firewall to another firewall

Edit Rule: To append IP address/es or to change the chosen fields of a selected rule

Edit Comment: To append, replace or change of the comment section of the selected rule/s

Add New Rule Above/Below: To add a new rule above or below of a selected rule

Change Owner: To change the owner or assign the owner of a rule

Rule Lock/Unlock: To lock a rule so that no one can act on it. It is an action that can be made by a super-user admin account.

5.1.1.2      NAT Rules #

In NAT Rule Viewer section all NAT rules that are configured be listed. It is possible to filter out just the needed NAT rules based on the following values.

Original Source: Original Source IP

Original Source Zone: Traffic originated from

Original Dst: Translated Source IP

Original Dst Zone: Traffic directed to

Original Services: Related traffic

Name: Name of the NAT rule

Comment: Comment if exists

The filtered rules can be exported using the Export button like in Rule menu. Again, like in Rule menu NAT Rule card can be customized based on the vendor.

5.1.1.3      Addresses #

All the object names will be listed on each firewall from here. Once an object is searched it will list the related object names that exist on firewalls. When the related object is selected all the rules using this object will be listed on rule viewer.

There is a filtering area in the Addresses menu. Using the fields in the following list the needed address objects can be listed easily.

Adress IP

Address Name

Address Type

Device IP

Device Name

Device Type

Reference Count

Virtual Firewall Name

5.1.1.3.1     Address Export #

The objects names listed on the screen can be exported as pdf or excel file to analyze them offline.

5.1.1.3.2     Address Edit (Automation Feature) #

It is possible to change the name or IP address of a selected address or adding a new Address object is possible here. This feature comes with Enterprise edition. If there is, one can easily select the necessary address/es to update easily via approval in place.

The following are the actions that can be taken on the related rules:

Rename Object: Changing the name of the Object is possible using this workflow. It is an operational workflow.

Change IP: Changing the IP address of any object is possible using this workflow. Since there is a change to the IP address the rules affected must be investigated by an approver via an approval process.

Add New Address: Adding a new address object is possible with this workflow. It is possible to add the same address on the selected firewalls with a single workflow. It is an operational workflow.

5.1.1.4      Address Groups #

All the group-object names will be listed on each firewall from here. Once a group-object is searched it will list the related group-object names that exist on firewalls. When the related object is selected all the rules using this group object will be listed on rule viewer.

There is a filtering area in the Address Groups menu. Using the fields in the following list the needed address objects can be listed easily.

Address Group Name

Device IP

Device Name

Device Type

Member IP

Member Name

Reference Count

Virtual Firewall Name

5.1.1.4.1     Address Group Export #

The object group names listed on the screen can be exported as pdf or excel file to analyze them offline.

5.1.1.4.2     Address Group Edit (Automation Feature) #

It is possible to change the name or member IP addresses of a selected address or adding a new Address Group object is possible here. This feature comes with Enterprise edition. If there is, one can easily select the necessary address Group/s to update easily via approval in place.

The following are the actions that can be taken on the related rules:

Rename Group: Changing the name of the Object is possible using this workflow. It is an operational workflow.

Append IP: Adding a new member to an object group will be handled with this workflow. Since there will be a change in the members the effect on the rules must be investigated by an approver.

Remove IP: Removing an IP address from a group will be handled with this workflow. It is an operational workflow.

Add New Address Group: Adding a new address group object is possible with this workflow. It is possible to add the same address group on the selected firewalls with a single workflow. It is an operational workflow.

5.1.2       Rule Checker #

Rule checker is a field that can be used to find out the existence of a rule on the firewalls. When given with the necessary IP and service information the system will make both a path analysis and will find each rule on each firewall.

There are following fields on Rule Checker tool:

Source IP: Source IP is the IP that traffic will start from. This can be a single(host-based) IP, range of IP addresses or IP subnet.

Destination IP: Destination IP is the final arrival point of the traffic.This can be a single(host-based) IP, range of IP addresses or IP subnet.

Select Protocol: Protocol of the traffic that is searched. This can be ALL meaning any traffic, a TCP or a UDP traffic.

Service Port: Service port that will be used for the traffic. For HTTP traffic this can be port 80, 8080 or any similar port that web service is enabled.

When all the fields are filled with the related information, the results “Continue” button be used. On the results page the firewalls that must be in place will be seen for this traffic to be established and if these firewalls already allowing the traffic or which ones are blocking it. For example, with the given information for TCP/80 traffic the rule checker result page shows traffic to be blocked.

On the results page after investigating the results there are two options; either come back to the previous page to change one of the parameters that is being searched for or create a new query. With the chosen method the tool will show the new results.

5.1.2.1       Topology Mode #

In topology mode the controlled IP addresses must exist on the network or a routing must exist from source to destination IP. If it is, then the system will show all the firewalls in path giving the information if there is access or not.

5.1.2.2       Non-routed Mode #

If the firewall is known or there is a missing routing, it is also possible to show if there is access on the selected firewall devices.

5.1.3       Network Topology #

Network topology is the graphical representation of all the firewalls and other L3 devices added to the system with their connections to each other. The topology can be zoomed in or out via mouse scroll or using the panel on upper right side. Also, it is possible to take a picture of this topology view in jpg format to use somewhere else. In this topology firewall icon locations, be changed easily and to make this place valid in future visits a “Save” button exists in the same panel.

There is a Search area on the left upper side of the screen. The purpose of this search area is to find out IP, the path of any traffic, the existence of a rule with the addition of service field. Like rule checker the system will find the path, but this time it will also show it on the topology. The path be seen via using a dotted line and rule existence is shown on each firewall on the path.

Here is a sample view of a topology to be drawn:

5.1.4       Usage Analysis #

Starting from 4.1.1 release usage analysis can be made for all the rules on the system since there is passive monitoring of all traffic logs. For rule&object usage the analysis will be started from Rule viewer for the selected rule and results be displayed in Usage Task List menu.

WARNING

Opinnate Collector must be installed after Opinnate Manager installation and first-time renewal for the caching of all policy data.

WARNING

On Global Area Collector Settings Page Collector IP address must be added with port 8081 like Collector IP:8081. Also, Trusted IP addresses for each firewall that are sending Syslog messages must also be configured.

5.1.4.1      Usage Task List #

Tasks will be displayed here along with their status. Tasks currently under monitoring will be labeled as “Running.” Once a task is completed, it will be marked as “Completed.” For completed tasks, the rules will be shown after the risk level is selected for rule usage analysis

5.1.4.2      Custom Usage #

Custom usage can be used to list any traffic for the selected period. To see the traffic for an IP address when that IP address is generated traffic or reached by other IP addresses or to see traffic for a specific service for the selected history. All results will be displayed in the Usage Task List menu like rule usage results.

5.1.5       Revision History #

For configuration changes done on firewalls including objects, object groups, VPNs and policy changes revision history menu be used. One can easily see the difference between the remaining version with the past ones.

Subjects: For each revision compare report subjects must be chosen. Here are the subject names that configuration updates to be seen:

Device Address

Device Address Group

Device Admins

Device App

Device App Group

Device Interface

Device Route

Device Schedule

Device Service

Device Service Group

IPSEC VPN

Policy

Devices: Each device integrated be listed here and the report will be generated for the chosen devices. By default, all devices are chosen.

Previous Revision: As the name implies past revision that is to be compared against

Next Revision: As the name implies next revision that is controlled.

Once the necessary fields are chosen report be generated and viewed on the next screen shown. One can see all the differences between each revision based on the additions, deletions or modifications.

5.1.6       Alert Composer #

The difference between each revision can be monitored using Alert Composer menu. From here four different alert schedules can be created. Once an alert is created system will start sending emails related to each situation:

Revision Compare: A report be generated and sent based on the criteria defined for the last two revisions.

Critical Rule Alert: If a permissive critical rule is found out on the last revision an email alert is sent.

Risky Rule Alert: If a risky rule is found out on the last revision an email alert is sent.

Policy Conflict Rule Alert: If a policy conflict rule is found out on the last revision an email alert is sent.

Real Time Configuration Alert: If there is a configuration change on firewall an alert mail will be sent immediately using this alert mechanism. Selection for change actions can easily be made in the opened page.

6        Compliance and Reporting – Lite, Standard, Enterprise #

When connected to the Compliance and Reporting module from the left bar menu the first page to be seen is the Compliance dashboard. Here there are several widgets that give information about the compatibility of firewalls to several regulations and issues related to being compliant with any regulation. All the widgets can be selected based on the user needs and it is user-customizable like other dashboards on the system.

Compliance Score: This widget shows the compliance score of the infrastructure against several regulations like NIST, PCI-DSS, ISO27001 and more. The score is calculated based on the items given in the related report on the reports section.

Compliance Score History: It would be meaningful to be able to see the score at a previous date. This widget handles this need and shows scores for each compliance.

Compliance Scores: This bar widget will be helpful to see each compliance score calculated on the system and gives a relative comparison.

Top Compliance Issues: This widget highlights the most important problems on the system based on the compliance and security needs.

Top Policy Violations: This widget highlights the most critical rules that needs attention. It would be rules being both conflicting and permissive critical and risky or a combination of them.

Last 5 Optimization Tasks: Last 5 tasks being completed on the system is shown here. To see which actions or on which date they are taken.

6.1.1       New Report #

There are several reports that can be supplied from the system. PCI-DSS, NIST, ISO27001, HIPAA, GDPR, SOX, SWIFT, BRSA and DTO reports that can be used for audit purposes. Apart from this, several different custom reports can also be generated. Reports that need to be generated will be defined on the New Reports page first and then generated reports be seen on the Reports page.

To generate a new report what kind of report is needed and if the report is to be scheduled or not will be configured here. 

Report Name: The name of the reports that will also be shown on the report be configured here.

Type: Type of report be chosen here. There are five different options here:

PCI-DSS: The report for PCI-DSS audit readiness. If chosen Subjects will be pre-populated

ISO27001: The report for ISO27001 audit readiness. If chosen Subjects will be pre-populated

NIST: The report prepared based on NIST framework on firewalls. If chosen Subjects will be pre-populated

HIPAA: The report prepared based on HIPAA framework on firewalls. If chosen Subjects will be pre-populated

GDPR: The report prepared based on GDPR framework on firewalls. If chosen Subjects will be pre-populated

SOX: The report prepared based on SOX framework on firewalls. If chosen Subjects will be pre-populated

SWIFT: The report prepared based on SWIFT framework on firewalls. If chosen Subjects will be pre-populated

DTO(TR): The report for DTO audit readiness. If chosen Subjects will be pre-populated

BRSA(TR): The report for BRSA audit readiness. If chosen Subjects will be pre-populated

Custom: The reports for special needs like permissive rule analysis.

Subject: Apart from custom reports, subjects will automatically be chosen here. For custom reports Subjects need to be identified here.

Devices: Reports to be prepared for which devices be chosen here. By default, all firewalls will be chosen.

Data Count: A summarized report or a detailed report can be chosen from here. The summary report shows the first 20 data on the related subject.

Orientation: The report orientation, either portrait or landscape chosen here.

Export Type: PDF or HTML report can be generated based on the selection here.

Enable Schedule: If the report needs to be prepared in regular intervals the schedule will be configured here.

Enable Notification: If notification is needed or for scheduled reporting email addresses will be identified here.

6.1.2       Reports #

When a new report request is made the prepared reports are listed in this menu. One-time reports and scheduled reports can be viewed in the same manner in the PDFs section of the related report request. Viewing or downloading the prepared report is possible as seen in the following. Updating a scheduled report is possible here using the View button.

6.1.3       Report Settings #

It is possible to change the logo that will be displayed in the generated reports. Simply uploading the preferred logo file using the upload button is needed. Apart from this, changing the columns of the rules in the generated reports and rule export can be made here. Colum preferences can be based on the vendors integrated and the orientation of the report.

7        Optimization Features – Standard, Enterprise #

With Optimization module it is possible to take actions on problematic conditions that are also given in Analysis module. There are several workflows related to each rule type that an action must be taken on. These are disabling of shadowed, expired, unused rules, cleaning of disabled rules and decommission of any IP address that is shut down on the environment, removing duplicated objects and consolidation of rules.

7.1.1       Disable Shadowed Rule #

Shadowed rules are the rules that are not processed for the related traffic because there is another rule above these rules in the policy table. Since these rules are processed for other traffic, they must be cleared, however in case of any problem these rules will be disabled with this workflow.

When the workflow is chosen a screen is displayed and it shows firewalls to be selected for this optimization. Either all or the chosen firewalls can be used for optimization. Since this is an optimization process there will be no approval in place in the workflow. For auditing purposes however, the reason part is used, and it is a mandatory requirement.

After the firewalls are chosen and an explanation is written in the Reason area the Continue button be used for the rules to be chosen. In the result page are there the shadowed rules. As seen in the following picture shadowing rule can be seen when clicking on the EYE icon seen on the right-hand side of the rule card. When clicked on it as seen in the following image the shadowing rule is shown.

When clicking on the DISABLE button, the optimization process is started for the chosen rules and the workflow status is seen on the task list.

If preferred clicking on the RULE REORDER button will reorder the rule upfront of the master rule when the master rule is a permissive rule especially.

7.1.2       Disable Expired Rule #

Expired rules are the rules that are non-functional since the validity period has already passed. Since these rules are not valid and have no function, they must be cleared, however in case of any problem these rules first be disabled with this workflow.

When the workflow is chosen from the list, the first screen to be seen is the firewall list containing all the firewalls within the environment. First, the firewalls to work on must be chosen from this list and the reason for this workflow must be specified. Also, how many number of days this expiration event happened before must be chosen. By default, this is 7 days and maximum of 365 days be chosen.

After the firewalls are chosen and the remaining fields are filled with necessary values, “Continue” button will be used to see which are the rules that are expired on these firewalls. The rules are seen as follows.

From the list of the rules on these firewalls the rules to be disabled must be chosen and by clicking on the DISABLE button the disabling workflow will begin and the workflow status starts to be seen in the task list.

7.1.3       Disable Unused Rule #

Unused rules are the rules not used for a while. Usage criteria may change from company to company and no usage of 90 days is the default value to be used. Unused rules are open gates on the firewalls and if it can be made sure that these are not used, they should be disabled immediately. The last used value on the related rule is used for the calculation of this information.

When this workflow is chosen the first screen to be displayed will be again the firewalls in the environment. First, the firewalls that will be worked on must be chosen. Afterwards the reason must be specified since it is a mandatory field. Last used days is by default 90 days or older however it can be made higher or lower than 90 days also.

After the firewalls are chosen and the remaining fields are filled with necessary values, “Continue” button will be used to see which are the rules that are unused on these firewalls. The rules be seen as follows.

From the list of the rules on these firewalls the rules to be disabled must be chosen and by clicking on the DISABLE button the disabling workflow will begin and the workflow result will be seen in the task list

7.1.4       Clean Disabled Rule #

Disabled rules are the rules that are non-functional since they are disabled. Disabled rules must be cleared from the policy table since they increase the complexity level of firewall policy table. These rules must be cleaned regularly; however, it is recommended that cleaning of disabled rules would be the first action of a regular optimization activity on Opinnate since other workflows will generate new disabled rules afterwards.

The first screen to be seen is firewalls like the other workflows. In this firewall list the firewalls that this workflow will be working on must be chosen. Also, the reason of this activity also must be specified like “Periodical Optimization”, etc.

When the firewall is chosen and Continue button is clicked next screen will be the rule list that are disabled. Rules will be seen like following:

After the selection of rules to be cleaned CLEAN button is to be used for this workflow to begin. Once it is started the task also be seen in the task list.

7.1.5       Remove Duplicated Objects #

It is general that a firewall may have different object names for the same server or servers, however it is not a preferred situation and may lead to confusion. With this feature all objects with the same IP information in it will be listed on each firewall. One can choose the preferred object name among these and start the workflow.

When the workflow started with a chosen object name on a firewall analysis page appears.

On this page:

IP Network: The IP address of the objects in common

Selected Object: The object name chosen or preferred to use.

Remove Object(s): Objects to be removed from firewall rules.

And the related rules that are using non-selected objects will be shown.

After pressing the Finish button, the system will start changing the object names with the chosen one and it will be shown on the Task List.

7.1.6       Decommission #

In a corporate environment there are servers that are being outdated or decommissioned from the environment. When this happens, the IP address belonging to this system will become empty and will possibly be used by other servers after a while. Therefore, the decommissioned server IP address must be cleared from the firewalls immediately. This process is automated with this workflow.

When this workflow is chosen the first thing to be done must be to write a reason statement about this activity. Also, the IP addresses must also be added to the list, if there is only one IP address then the flow will be just for it.

After adding the IP addresses to the list and clicking on CONTINUE button the rules, and objects groups having the IP addresses in it will be listed. Using the Select All button and clicking on FINISH button all the appearances of the IP addresses will start to be removed with this workflow. There will be three different options based on the rules:

• IP address to be removed from the rules: The IP address is not the single value on source or destination.
• Rules to be disabled: The IP address is the single value on source or destination.
• IP removed from the group object: The IP address will be removed from the group-object since there are other IP addresses in the group.

7.1.7       Scheduled Tasks #

It is possible to schedule optimization tasks in this menu. This way disabling shadowed rules, disabling expired rules, disabling unused rules and cleaning disabled rules tasks be scheduled so that there will be no need to connect to the system to do this optimization activities. It will be a zero-touch optimization activity.

When selected one of the workflows in the list a new settings page will be displayed to get additional information.

Task Type: The chosen workflow. It can be a disabling or deleting activity.

Task Name: The task should have a name to distinguish the workflow among the same type of workflows.

Period: The frequency of this optimization activity will be configured here. It can be DAY, WEEK or HOUR.

Rule Count: The number of firewall rules that action should be taken on. It is recommended to set this value as a high number to be sure all the related rules are eliminated.

Devices: This scheduled optimization activity can be taken on just the selected firewalls here.

Email Address: Once the task is complete an email will be sent to the recipient address configured here.

7.1.8       Rule Consolidation #

Starting from 3.2.1 release rules having more than one field common can be consolidated using this workflow to lower the total number of rules on the firewalls. It is possible to consolidate rules either adding a new rule or consolidating them in the upper rule.

8        Automation Features – Enterprise #

As to Automation module, all policy change operations can be handled through Opinnate with Approval process in place. Standard rule creation, IP access cloning and custom rule creation processes can be identified and completed here. Checking against corporate security policy matrix is also available for approval process automation. Detailed information about each workflow will be detailed here.

8.1.1       Add New Rule #

Creating manual policy change request action be started in this menu. Any admin user created on the system can access this menu to create a new rule request. Add New Rule is a 3-step workflow. In the first step the request is identified, second step is for approval of the request. Once the request is approved the last step, meaning the path analysis and final control should be handled by firewall admin user if everything is ok.

8.1.1.1      Request #

For the identification of the request there are several fields that are also needed for rule creation on the firewall. The following are the fields and their meanings or purpose of use.

Source IP: Source IP is the IP that traffic will start from. This can be a single(host-based) IP, range of IP addresses or IP subnet. Using the + button any number of IP address data can be added for rule creation.

Destination IP: Destination IP is the final arrival point of the traffic.This can be a single(host-based) IP, range of IP addresses or IP subnet. Using the + button any number of IP address data can be added to the request.

Domain: Domain of the user if user-based policy is to be created.

Application: Application can be selected from here.

Username: Username or security group to be chosen from the list.

Schedule: The validity of the request that will be defined will be identified here. If there is no limit for validity, then Always tick box must be chosen.

Reason: It is the explanation or reason for the request. There is a 15-character bottom limit here for the requester to give clear information and approver understands it.

Comment: External ticket number can be configured here

Select Protocol: Protocol of the traffic that is needed. This can be ALL meaning any traffic, a TCP, a UDP or an ICMP traffic.

Service Port: Service port that will be used for the traffic. For HTTP traffic this can be port 80, 8080 or any similar port that web service is enabled. Using the + button any number of service ports be requested.

Reverse Policy: If the rule is wanted to be created bidirectionally this toggle button can be used.

Customize Access Role: For Check Point firewalls, if there is a Check Point firewall on the path the needed Access Role name can be given here, otherwise it is automatically created using Task name.

Excel Import: For requests having several IP addresses or services it is possible to import the request fields using this area.

Once all the information is given, so the request is identified, all three boxes be filled and it is time to start or open the ticket. Pressing the Add Rule button request is initiated, and it will start being seen in the task list.

8.1.1.2      Approval #

When the request is initiated corporate security policy check process is started in the back end. The process will identify if the requested policy is compliant to security policy or not. If it is in parallel to security policy then it means a compliancy, if it is not in parallel to it means the requested rule-pair is not compliant. If there is nothing exist on the security policy, then it means not a match condition. In the approval step these are the following fields:

SourceEnv: The corporate security policy matching environment value to the Source IP address requested.

DestEnv: The corporate security policy matching environment value to the Destination IP address requested.

Source: Source IP address, the traffic be initiated.

Destination: Destination IP address, the traffic will reach

Service: Requested service port

Status: If the security policy is parallel to the request, then it says Match, not parallel then it says Conflict, no matching then it says No Match.

Description: Detailed information about the compliance to the corporate policy given here

Schedule: Requested validity period

Reverse: If the rule is also requested reverse

Reason: Reason statement

Risky: Risky condition

Permissive: Permissiveness level

Apart from compliance to the corporate policy the rule’s being permissive or risky condition also starts to be given starting from 4.1.1 release.

In this step the approver will get a notification email first about the new rule that must be acted on. Once connected to the system the approver will get information about the request in detail and brief information about matching condition as a Description. Finally looking at the reason information supplied in the request the approver will decide on what to do. If the request to be approved, then Approve button be used by the approver. Approver may also get additional information from the requester or change the validity of the request before approving.

8.1.1.3      Analysis #

Before this step a path analysis is made in the back end to give information about what path the requested traffic will follow. And, which firewalls the rule change must be applied on. This step is a control step for firewall admins to see if everything is analyzed as expected. Apart from the source, destination, and service fields there are the following fields that can be seen:

Schedule: Time schedule that will be applied on the firewall be given here. It may be different than the request since the approver may change it.

From: The firewall interface that the traffic is coming from. It will be shown once the related firewall icon is clicked.

To: The firewall interface that the traffic be forwarded to. It will be shown once the related firewall icon is clicked.

Apart from path analysis if there is a similar rule exists, or the access exists on the firewall is also identified and the information be given to the firewall admin. Based on the information given the firewall admin can decide to consolidate the rule with a rule already existing on firewall.

In this step the firewall admin will get a notification email first about the new rule that must be acted on. When connected, firewall admin will see the routing information, the IP addresses that will be applied to the rule and the ticket number that will be used for the comment section on the firewall. If everything is ok, then for the automation to be started, firewall admin must click on Finish button. And the process for applying rules on the firewalls begins. Once the process is finished the task status becomes completed and firewall admin can analyze the process result on the result page of the process.

8.1.2       Server Cloning #

When the destination and the service information somehow is not known by the requester, they may need firewall admin copy firewall policies belonging to some other server. This feature is for this need and to make a new workflow Server Cloning menu is used. This is a 3-step process also and the process begins by identification of the request, afterwards approval takes place and lastly Result step comes into play.

8.1.2.1      Request #

For the identification of the cloning request there are a couple of fields. The following are the fields and their meanings or purpose of use.

Reason: The reason for the cloning request. This field is a mandatory field, and the supplied information is for the approver to make the evaluation accordingly.

Reference IP: The cloned IP address is already active in the environment. All the policies using this IP address are found out.

New IP: New IP address/es to be added to the environment. The policies needed will be found out and even if the new IP address is on another subnet the policy be created.

Once all the information is submitted, “Continue” button should be used for the next step to begin.

8.1.2.2      Approval #

When the request is initiated corporate security policy check process is started in the back end. The process will identify if the requested policy is compliant to security policy or not. In the approval step there are the following fields:

SourceEnv: The corporate security policy matching environment value to the Source IP address requested.

DestEnv: The corporate security policy matching environment value to the Destination IP address requested.

Source: Source IP address, the traffic be initiated.

Destination: Destination IP address, the traffic will reach

Service: Requested service port

Status: If the security policy is parallel to the request, then it says Match, not parallel then it says Conflict, no matching then it says No Match.

Description: Detailed information about the compliance to the corporate policy given here

Schedule: Requested validity period

Reverse: If the rule is also requested reverse

Reason: Reason statement

Risky: Risky condition

Permissive: Permissiveness level

The rules are identified based on the reference IP address being in the source or destination fields on the remaining rules. New IP addresses/es are shown and regarding rules are calculated against corporate policy.

In this step the approver will get a notification email first about the new rule that must be acted on. Once connected to the system the approver will get information about the request in detail and brief information about matching condition as a “Description”. Finally looking at the reason information supplied in the request the approver will decide on what to do. If the request to be approved, then Approve button be used by the approver.

8.1.2.3      Analysis #

Before this step a path analysis be done in the back end to give information about what path the requested traffic will follow. And, which firewalls the rule change must be applied on. This step is a control step for firewall admins to see if everything is analyzed as expected. Apart from the source, destination, and service fields there are the following fields that can be seen:

From: The firewall interface that the traffic is coming from. It will be shown once the related firewall icon is clicked.

To: The firewall interface that the traffic be forwarded to. It will be shown once the related firewall icon is clicked.

In this step the firewall admin will get a notification email first about the new rule that must be acted on. When connected, firewall admin will see the routing information, the IP addresses that will be applied to the rule and the ticket number that will be used for the comment section on the firewall. If everything is ok, then for the automation to be started firewall admin must click on Finish button. And the process for applying rules on the firewalls begins. Once the process is finished the task status becomes completed and firewall admin can analyze the process result on the result page of the process.

8.1.3       Add New Rule Path Free #

Creating policy change request without path analysis is started in this menu. Firewall admin users created on the system can access this menu and create a new rule request. Add New Rule Path Free is a 4-step workflow. In the first step the request is identified, second step is for approval of the request. Third is device selection and the last step, meaning the analysis step in which firewall admin clicks on finish button for the process to be started.

8.1.3.1      Request #

For the identification of the request there are several fields that are also needed for rule creation on the firewall. The following are the fields to be filled.

Source IP: Source IP is the IP that traffic will start from. This can be a single(host-based) IP, range of IP addresses or IP subnet. Using the + button any number of IP address data can be added for rule creation.

Destination IP: Destination IP is the final arrival point of the traffic.This can be a single(host-based) IP, range of IP addresses or IP subnet. Using the + button any number of IP address data can be added to the request.

Domain: Domain of the user if user-based policy is to be created.

Application: Application can be selected from here.

Username: Username or security group to be chosen from the list.

Schedule: The validity of the request that will be defined will be identified here. If there is no limit for validity, then Always tick box must be chosen.

Reason: It is the explanation or reason for the request. There is a 15-character bottom limit here for the requester to give clear information and approver understands it.

Comment: External ticket number can be configured here

Select Protocol: Protocol of the traffic that is needed. This can be ALL meaning any traffic, a TCP, a UDP or an ICMP traffic.

Service Port: Service port that will be used for the traffic. For HTTP traffic this can be port 80, 8080 or any similar port that web service is enabled. Using the + button any number of service ports be requested.

Reverse Policy: If the rule is wanted to be created bidirectionally this toggle button can be used.

Customize Access Role: For Check Point firewalls, if there is a Check Point firewall on the path the needed Access Role name can be given here, otherwise it is automatically created using Task name.

Excel Import: For requests having several IP addresses or services it is possible to import the request fields using this area.

Once all the information is given, so the request is identified all source, destination, service and reason boxes be filled at least and it is time to start or open the ticket. Pressing the Add Rule button request is initiated, and it will start to be seen in the task list.

8.1.3.2      Approval #

When the request is initiated corporate security policy check process be started in the back end. The process will identify if the requested policy is compliant to security policy or not. If it is parallel to security policy then it means a compliancy, if it is not parallel to it means the requested rule-pair is not compliant. If there is nothing exist on the security policy, then it means not a match condition. In the approval step there are the following fields:

SourceEnv: The corporate security policy matching environment value to the Source IP address requested.

DestEnv: The corporate security policy matching environment value to the Destination IP address requested.

Source: Source IP address, the traffic be initiated.

Destination: Destination IP address, the traffic will reach

Service: Requested service port

Status: If the security policy is parallel to the request, then it says Match, not parallel then it says Conflict, no matching then it says No Match.

Description: Detailed information about the compliance to the corporate policy given here

Schedule: Requested validity period

Reverse: If the rule is also requested reverse

Reason: Reason statement

Risky: Risky condition

Permissive: Permissiveness level

In this step the approver will get a notification email first about the new rule that must be acted on. Once connected to the system the approver will get information about the request in detail and brief information about matching condition as a description. Finally looking at the reason information supplied in the request the approver will decide on what to do. If the request to be approved, then Approve button be used by the approver. Approver may also get additional information from the requester or change the validity of the request before approving.

8.1.3.3      Select Device #

This time path analysis is not made since the firewalls on which the rules to be implemented are chosen from the list.

Apart from this, a new criteria different from the device setting can be configured for each firewall to be used. Here are the criteria list for each vendor:

Fortinet:

From

To

SSL Profile

AV Profile

IPS Profile

APP Control

DNS Filter

WEB Filter

NAT

Palo Alto:

From

To

Security Group Profile

URL Category Profile

Log Profile

Check Point:

Layer

Policy Package

8.1.3.4      Analysis #

If everything is ok, then firewall admin must click on Finish button for the automation workflow to be started. And the process for applying rules on the firewalls begins. Once the process is finished the task status becomes completed and firewall admin can analyze the workflow result on the result page of the process.

8.1.4       Server Cloning Path Free #

Path-free server cloning is for the cloning or use of the same policies meaning when the new IP address is not on another subnet. This is a 3-step process and the process begins by identification of the request, afterwards approval takes place and lastly Result step comes into play.

8.1.4.1      Identification #

For the identification of the cloning request there are a couple of fields. The following are the fields and their meanings or purpose of use.

Reason: The reason for the cloning request. This field is a mandatory field, and the supplied information is for the approver to make the evaluation accordingly.

Reference IP: The cloned IP address that is already active in the environment. All the policies using this IP address will be found out.

New IP: New IP address/es to be added to the environment. The policies needed will be found out and even if the new IP address is in another subnet the policy is created.

Once all the information is submitted, “Continue” button be used for the next step to begin.

8.1.4.2      Approval #

When the request is initiated corporate security policy check process be started in the back end. The process will identify if the requested policy is compliant to security policy or not. In the approval step there are the following fields:

SourceEnv: The corporate security policy matching environment value to the Source IP address requested.

DestEnv: The corporate security policy matching environment value to the Destination IP address requested.

Source: Source IP address, the traffic be initiated.

Destination: Destination IP address, the traffic will reach

Service: Requested service port

Status: If the security policy is parallel to the request, then it says Match, not parallel then it says Conflict, no matching then it says No Match.

Description: Detailed information about the compliance to the corporate policy given here

Schedule: Requested validity period

Reverse: If the rule is also requested reverse

Reason: Reason statement

Risky: Risky condition

Permissive: Permissiveness level

In this step the approver will get a notification email first about the new rule that must be acted on. Once connected to the system the approver will get information about the request in detail and brief information about matching condition as a “Description”. Finally looking at the reason information supplied in the request the approver will decide on what to do. If the request is to be approved, then Approve button be used by the approver.

8.1.4.3      Analysis #

This time path analysis is not made since the firewalls and the related rules existing on the firewalls are listed here. From here if all the policies are to be written all policies must be selected. However, it is not an obligation, meaning just the policies on a specific firewall may be chosen to clone. Once the selection is made and if everything is ok, then for the automation to be started firewall admin must click on Finish button. And the process for applying rules on the firewalls begins. Once the process is finished the task status becomes completed and firewall admin can analyze the process result on the result page of the process.

8.1.5       Add New Custom Rule #

It is possible to create a new rule on a specific firewall like on a firewall manager or firewall itself starting from 4.1.1 release. In this workflow like other change flows on Opinnate there are 3 steps that also includes approval. Like on a firewall device, firewall admin can use the addresses, address groups or services that already exists on firewall directly. Differing from other flows it is a demand-based workflow not a request-based flow.

8.1.5.1      Select Device #

The first step for custom new rule workflow is to identify which firewall to act on. So, in this step firewall device will be selected. It is possible to select only one device from the list since it will be a firewall rule specific to a related device. After the selection the task will be seen in the task list as Pending Request status.

8.1.5.2      Request #

For the identification of the request there are several fields that are also needed for rule creation on the firewall. The following are the fields to be filled.

Source IP: Source IP is the IP that traffic will start from. This can be a single(host-based) IP, range of IP addresses or IP subnet. Using the + button any number of IP address data can be added for rule creation.

Src Address List: It is possible to select the address object from the firewall using this field.

Destination IP: Destination IP is the final arrival point of the traffic.This can be a single(host-based) IP, range of IP addresses or IP subnet. Using the + button any number of IP address data can be added to the request.

Dst Address List: It is possible to select the address object from the firewall using this field.

Select Protocol: Protocol of the traffic that is needed. This can be ALL meaning any traffic, a TCP, a UDP or an ICMP traffic.

Service Port: Service port that will be used for the traffic. For HTTP traffic this can be port 80, 8080 or any similar port that web service is enabled. Using the + button any number of service ports be requested.

Service List: It is possible to select the service object from the firewall using this field

Domain: Domain of the user if user-based policy is to be created.

Application: Application can be selected from here.

Username: Username or security group to be chosen from the list.

Schedule: The validity of the request that will be defined will be identified here. If there is no limit for validity, then Always tick box must be chosen.

Reason: It is the explanation or reason for the request. There is a 15-character bottom limit here for the requester to give clear information and approver understands it.

Comment: External ticket number can be configured here

Reverse Policy: If the rule is wanted to be created bidirectionally this toggle button can be used.

Apart from these, depending on the vendor selection following are the additional fields that can be configured for the related firewall

Fortinet:

From

To

SSL Profile

AV Profile

IPS Profile

APP Control

DNS Filter

WEB Filter

NAT

Palo Alto:

From

To

Security Group Profile

URL Category Profile

Log Profile

Check Point:

Layer

Policy Package

Once all the information is given, so the request is identified all source, destination, service and reason boxes are filled at least and it is time to start or open the ticket. Pressing the Add Rule button request is initiated, and it will start to be seen in the task list as Pending Approval.

8.1.5.3      Approval #

When the request is initiated corporate security policy check process be started in the back end. The process will identify if the requested policy is compliant to security policy or not. If it is parallel to security policy then it means a compliancy, if it is not parallel to it means the requested rule-pair is not compliant. If there is nothing exist on the security policy, then it means not a match condition. In the approval step there are the following fields:

SourceEnv: The corporate security policy matching environment value to the Source IP address requested.

DestEnv: The corporate security policy matching environment value to the Destination IP address requested.

Source: Source IP address, the traffic be initiated.

Destination: Destination IP address, the traffic will reach

Service: Requested service port

Status: If the security policy is parallel to the request, then it says Match, not parallel then it says Conflict, no matching then it says No Match.

Description: Detailed information about the compliance to the corporate policy given here

Schedule: Requested validity period

Reverse: If the rule is also requested reverse

Reason: Reason statement

Risky: Risky condition

Permissive: Permissiveness level

In this step the approver will get a notification email first about the new rule that must be acted on. Once connected to the system the approver will get information about the request in detail and brief information about matching condition as a description. Finally looking at the reason information supplied in the request the approver will decide on what to do. If the request to be approved, then Approve button be used by the approver. Approver may also get additional information from the requester or change the validity of the request before approving.

8.1.5.4      Analysis #

If everything is ok, then firewall admin must click on Finish button for the automation workflow to be started. And the process for applying the rule on the firewall begins. Once the process is finished the task status becomes completed and firewall admin can analyze the workflow result on the result page of the process.

  #

8.1.6       Rule Viewer Automation Workflows #

8.1.6.1      Disable Rule #

Any rule can be selected from rule viewer and then using the edit button on the upper-right side of rule viewer disable workflow can be started. Once the workflow is completed the new state of the rule be seen on the rule viewer. Also, workflow status be seen from the task list.

8.1.6.2      Enable Rule #

Any disabled rule can be selected from rule viewer and then using the edit button on the upper-right side of rule viewer enable workflow can be started. Once the workflow is completed the new state of the rule be seen on the rule viewer. Also, workflow status be seen from the task list.

8.1.6.3      Delete Rule #

Any disabled rule can be selected from rule viewer and then using the edit button on the upper-right side of rule viewer delete workflow can be started. Once the workflow is completed the rule starts not to be listed on rule viewer. Also, workflow status be seen from the task list.

8.1.6.4      Rule Reorder #

Any rule selected can be moved to another position using this workflow. Top, Bottom, Above/Below of a selected rule are possible positions that can be selected.

8.1.6.5      Edit Rule #

One can easily change a rule that is already created with this workflow. There are two options for rule edition. Append a Rule and Update a Rule.

8.1.6.5.1     Append to Rule #

Appending on source, destination or both source and destination fields of a rule or selected rule groups are possible with this workflow. The selected rules may be on different firewalls. Once a rule or rule group is selected and the Append Rule option is chosen a pop-up screen opens. On this pop-up screen:

Source: When selected this radio button only append will be made to the source field.

Destination: When selected this radio button only append will be made to the destination field.

Source&Destination: When selected this radio button only append will be made to the source and destination fields.

IP Address: More than one IP address or IP network can be added with the + button.

Reason: Reason to be shown to approver.

After necessary actions the process, be started and the approval step begins. Like in Add New Rule workflow approver will see the requested change details and if it is appropriate to corporate policy. If decided to approve, analysis step starts, and firewall admin will see what actions to be taken last time. If the firewall admin clicks on the Finish button the system will start acting on the related firewalls. If everything is working normally the workflow will be finished with success and reported this way. 

8.1.6.5.2     Update a Rule #

Updating on any field of a single rule would be handled with this workflow. One can change source, destination, or service fields of a single rule. Once chosen a rule and selected this workflow a pop-up screen opens. On this pop-up screen:

From: Source interface can be edited using this field

To: Destination interface can be edited using this field

Src Address List: Selecting from object list on the firewall

Dst Address List: Selecting from object list on the firewall

Source IP: Ip address from object list, or a new IP address can be added or already added IP addresses may be removed from this field.

Destination IP: Ip address from object list, or a new IP address can be added or already added IP addresses may be removed from this field.

Protocol/Port: New Protocol and port number will be chosen if needed or already added ones may be removed from this field.

FQDN: If needed FQDN address can be added

Reason: Reason to be shown to approver.

Schedule: Schedule can be edited here

Comment: External ticket number can be configured here

After necessary actions the process, be started and the approval step begins. Like in Add New Rule workflow approver will see the requested change details and if it is appropriate to corporate policy. If decided to approve, analysis step starts, and firewall admin will see what actions to be taken last time. If the firewall admin clicks on the Finish button the system will start acting on the related firewall. If everything is working normally the workflow will be finished with success and reported this way. 

8.1.6.6      Edit Comment #

There are three options for the edition of the comment field. Append, Replace and Update. Each option will be detailed in the following section:

8.1.6.6.1     Append Comment #

Appending comment can be achieved for more than one firewall rule no matter if the rules are on the same firewall. Once rule/s is/are chosen and this workflow is selected a pop-up screen showing the comment value to be given for append. When the input is written and append button be used workflow be started and new comment be added as requested.

8.1.6.6.2     Replace Comment #

Replacing comment can be achieved for more than one firewall rule no matter if the rules are on the same firewall. Once rule/s is/are chosen and this workflow is selected a pop-up screen showing the comment value to be given for replacement. When the input is written and replace button be used workflow be started and new comment be seen as the comment as requested.

8.1.6.6.3     Update Comment #

Updating comments can be achieved for only one firewall. Once the rule is chosen and this workflow is selected a pop-up screen showing the comment value to be given for update. When the input is written, an update button be used workflow be started and new comment be seen as requested.

8.1.6.7      Add New Rule #

Adding a completely new rule either above or below of a selected rule can be initiated using this workflow. Following are the fields to be filled for this workflow to begin.

Source IP: Source IP is the IP that traffic will start from. This can be a single(host-based) IP, range of IP addresses or IP subnet. Using the + button any number of IP address data can be added for rule creation.

Destination IP: Destination IP is the final arrival point of the traffic.This can be a single(host-based) IP, range of IP addresses or IP subnet. Using the + button any number of IP address data can be added to the request.

Domain: Domain of the user if user-based policy is to be created.

Application: Application can be selected from here.

Username: Username or security group to be chosen from the list.

Schedule: The validity of the request that will be defined will be identified here. If there is no limit for validity, then Always tick box must be chosen.

Reason: It is the explanation or reason for the request. There is a 15-character bottom limit here for the requester to give clear information and approver understands it.

Comment: External ticket number can be configured here

Select Protocol: Protocol of the traffic that is needed. This can be ALL meaning any traffic, a TCP, a UDP or an ICMP traffic.

Service Port: Service port that will be used for the traffic. For HTTP traffic this can be port 80, 8080 or any similar port that web service is enabled. Using the + button any number of service ports be requested.

Reverse Policy: If the rule is wanted to be created bidirectionally this toggle button can be used.

Customize Access Role: For Check Point firewalls, if there is a Check Point firewall on the path the needed Access Role name can be given here, otherwise it is automatically created using Task name.

The remaining steps will be the same with Add New Rule workflow, this time there is no path analysis need.

8.1.6.8      Change Owner #

Assigning or changing an owner to a rule can be made using this option. Email address is used for the definition of the rule owner for sending alerts. Change owner is used for rule lifecycle management. There are two use cases for RLM:

1. Expiring rules management: This use case is for sending alerts to the rule owner of a specific rule that Schedule is enabled, and Schedule date is about to come. With this alert it is aimed that the owner of the rule being aware of expiry and take necessary action if the rule is still needed.
2. Yearly checks for need: For each rule based on their creation date, alerts be sent to the rule owner of each user to get the information about the rule’s need. Based on the collected information unnecessarily enabled rules would be disabled or deleted.

8.1.6.9      Rule Lock/Unlock #

Some rules may not be preferred to be acted on. For this kind of rules, it is possible to lock the rule so that no one can act on the rule. This locking or unlocking activity can only be done by a super-user admin.

8.1.7       Address Viewer Automation Workflows #

Edition of an object can be achieved in two ways. One is object name change and the other is IP change.

8.1.7.1      Rename Object #

The name of an object can be changed with this workflow. For this workflow to begin an object must be chosen from the object list. Once chosen and the Name Change workflow is selected a pop-up screen be shown for changing the name. After writing the new name and pressing the change name button the system will start acting on it and change the name accordingly.

8.1.7.2      Change IP Address #

IP of an object can be changed with this workflow. For this workflow to begin an object must be chosen from the object list. Once chosen and IP Change workflow be selected a pop-up screen be shown for IP change. When workflow starts it will go for approval since there is a change and needs attention. Like Add New Rule workflow approval process will be handled by the approver and it will go to the analysis step. On this step if the firewall admin presses Finish button workflow will be started and IP will be changed for the object name.

8.1.7.3      Add New Address #

Adding a completely new address object is possible using this workflow. Address can be created on selected devices at once. Since there is no change on the rule site it is an operational workflow that does not need approval.

8.1.8       Address Group Viewer Automation Workflows #

Edition of an object-group can be achieved in three ways. One is object-group name change, the other is Append IP and the other is Remove IP workflow.

8.1.8.1      Rename Group #

The name of an object-group can be changed with this workflow. For this workflow to begin an object-group must be chosen from the object-group list. Once chosen and the Name Change workflow is selected a pop-up screen be shown for changing the name. After writing the new name and pressing the change name button the system will start acting on it and change the name accordingly.

8.1.8.2      Append IP #

A new IP address can be added by this workflow. Once this workflow is chosen a pop-up screen appears to add new IP address/es to the group. After adding the IP address/es to the group and pressing the Append button below Opinnate will connect to the firewall to take the action.

8.1.8.3      Remove IP #

IP address can be removed by this workflow. Once this workflow is chosen a pop-up screen appears to select the IP address/es to be removed from the group. After removing the IP address/es from the group and pressing the Remove button below Opinnate will connect to the firewall to take the action.

8.1.8.4      Add New Address Group #

Adding a completely new address group object is possible using this workflow. Address-groups can be created on selected devices at once. Since there is no change on the rule site it is an operational workflow that does not need approval.

9        Task List #

Task lists are the tasks to be queued generated on the system. These tasks may be automation tasks like Add New Rule or optimization tasks like Clean Disabled Rules. In this task list all the tasks created so far have been seen and detailed searches can be made on them using the Filter section like Rule Viewer. There are the following fields on the task list. These can also be used for filtering purposes.

ID: The internal ticket number

Ticket ID: The external ticket number coming from the service desk.

Type: Automation or Optimization task type like Add New Rule.

Owner: Person created the ticket.

Approver: Person that made approval action.

Operator: Person that made the operation action.

Status: There are five fields that are Working On, Pending Approval, Pending Operation, Action Needed and Completed.

Create Time: Time of the creation of the ticket.

Action: Edit or Delete activity on a ticket that is not completed

Status of the ticket will be detailed as following:

Working On: When a ticket is created it will be on working status during this status policy check is handled.

Pending Approval: The state where Approver is to be waited for the action.

Pending Operation: The state where Firewall Admin is waited for the action.

Pending Request: When the request is not completed or initiated this status will be shown.

Action Needed: If there is a problem during handling the task on the firewalls this state be used.

Completed: When the action is completed successfully the ticket be closed with this status.

10    Troubleshooting and Support #

During normal operation if there is a problem regarding system functioning and if it is sure that the infrastructure is not causing the problem then it must be further investigated by Opinnate support team. For the support team to make further analysis debug file will be needed. Debug files can be generated from the global settings menu.

11    Glossary #

Alert Composer
A workflow used to configure email alerts.

API
Refers to application programming interface and used for intercommunication of systems.

Audit
It is referred to make analysis for a specific set of control items if they are compliant or not.

Authorization
Once an authentication is completed, giving permission to make specific actions on the system.

BRSA
A Turkish regulation for finance companies.

Cluster
Means two devices working in sync not to face any service failure.

Collector
The independent component of Opinnate that is working on another server to collect syslog messages from firewalls.

Compliance
Compliance refers to the act of conforming to a set of rules, regulations, or laws that govern a particular industry, organization, or business activity.

Corporate Security Policy
Security policy of a corporation having statements about specific access restrictions.

Dashboard
A collection of graphical images to show summary information about a system.

Debugging
All system and code-level log messages seen in this level of logging.

DTO
A Turkish regulation belonging to the Turkish Republic Presidency.

Firewall
Firewall is a basic network security device that controls access between servers or IP addresses.

Firewall Admin
Firewall admin is the user having rights to take action on firewalls.

Global Area
Global Area is the main area on Opinnate NSPM that general settings to be applied.

Helpdesk
The system used to create new service requests.

HIPAA
A healthcare industry regulation.

Infosec Admin
Infosec admin is the user for information security teams and having related rights on the system.

ISO27001
An ISO regulation related to the IT Security industry.

LDAP
Protocol used to read directory information from the directory database.

Logging
Act of sending log messages to a syslog server.

Master
Refers to the shadowing rule.

Monitoring
Refers to periodically checking if a system is working as expected by the aid of several different monitoring algorithms.

Multitenancy
A feature giving customers different authorization and authentication levels for them to see their device details or configuration.

Network Topology
A topology showing connections between network endpoints.

NIST
A globally recognized compliance related to overall security maturity.

PCI-DSS
A regulation for the finance industry regarding credit card data.

Policy Analysis
Policy analysis is an action that is acted on firewall rules for specific conditions such as usage of the rule, etc.

Port
Refers to service ports for TCP and UDP protocols. The ports can be between 0-65535.

Protocol
Refers to IP protocols TCP and UDP that are widely used.

Revision
The latest version of configuration on firewalls.

Routing
Forwarding traffic between different IP subnets.

Rule
Refers to a firewall rule that enables access from a source IP address to a destination IP address.

Rule Usage
A workflow that enables collecting real usage on firewalls.

Service Port
It is the same as port.

SMTP
Protocol used to send and receive emails between client and server systems.

SOX
A US federal law in the finance industry.

Subnet
Subnet is a smaller set of IP addresses of IP classes.

Super User
Super-user is the user having all rights to manage the system.

Switch
Is a network component used to connect endpoints.

SWIFT
A regulation related to SWIFT usage data.

Syslog
A protocol that is used for sending log messages generated internally.

Ticket
On service desk systems, each event or request is also called a ticket.

Vendor
Refers to companies developing products in the security and network industry.

Virtual Area
Virtualization is used for isolation purposes.

Virtual Firewall
Is a firewall working as a subsystem of a physical firewall acting as a regular firewall.

12    Disclaimer #

This user guide is provided as a convenience and for informational purposes only. The contents of this guide are subject to change without notice and may contain technical inaccuracies or typographical errors.

This guide is not intended to be a substitute for professional advice, and we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability with respect to the guide or the information, products, services, or related graphics contained in the guide for any purpose. Any reliance you place on such information is therefore strictly at your own risk.

We disclaim all liability and responsibility arising from any reliance placed on the contents of this guide. Any use of this guide and its contents is at your own risk, and we will not be liable for any damages or losses of any kind arising from the use of this guide or the information contained therein.

This guide may contain links to third-party websites or resources. We do not endorse and are not responsible for the content, accuracy, or reliability of any third-party websites or resources that may be accessed through this guide.