Copyright© 2023, 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 1.1.1.

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

This product can only be used on a server with the mentioned Operating System and version:

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 misconception, 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 is working, 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 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 Upload License file button and now the system is ready.

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 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 models 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 Lite model 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 on firewall policies. 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, CBDDO.

Reporting:

Both for compliance purposes and special needs 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 used, or hardening must be done manually if optimization is not in place. Cleaning of all the analyzed 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 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. System is coming with one virtual area so, if there is a segmentation need this license must be purchased. Firewall 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 part.

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 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 pages 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 also is created which can be deleted once a new super-user added to the admin users.

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 can not 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 is not editable so are their names.

3.3         System Settings #

General settings for the whole system be configured in this panel. There are five different pages be seen on this page. The first one is the “System Configuration” where one can get the configuration backup of the system. And uploading of the backup file is also managed here. The second page is “Syslog Settings”. As the name implies syslog servers to which system logs be sent be configured on this page.

On “Settings” page the server IP settings can be seen and updated. Apart from server settings the ticket naming standard and time period system will be renewing data on the system would be configured. Help Desk IP address and Collector IP addresses must also be defined here.

On “Logs&Debugging” page all system global area logs be seen in detail. Debugging is used for the purpose of downloading error logs for support cases.

On Licensing page system licenses be seen and new license be added.

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 virtual area dashboard. Here there are several charts showing the overall status of the environment. The charts 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 devices menu or by clicking on this chart.

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 chart.

Shadowed Rules: Number of shadowed rules can be found on this chart. Shadowed rules are the rules that are not processed because there is another rule in front of 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.

Expired Rules: Number of expired rules can be found on this chart. 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 chart. 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 generally be disabled first.

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 incompliancy. If the rules are necessary to use then change on the corporate security policy must be thought and documented accordingly. Rules that are not compliant to 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 message when there is a 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.

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 three different levels: 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.

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.

Apart from these charts there are additional ones showing information about active tickets on the system, last tickets created, firewall devices and their related statistics.

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 that the necessary devices to be integrated. This integration is to be done on 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 Devices menu. From here if the connection is successful a check icon is seen near the related device. Using Edit button, the configuration parameters of the related device can be updated. Using 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.

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

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

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.

WARNING

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

	ATTENTION
	Be sure to make test when configuration is finished.

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.2         Analysis Features #

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

4.2.1        Rule Viewer #

Rule viewer is the part of the system where detailed search 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 common used parameters like Device Vendor, Source IP, etc..

There is a filtering area just above the rule viewer 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 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

4.2.2        Rule Checker #

Rule checker is a field that can 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 to see 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 also 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.

4.2.3        Network Topology #

Network topology is the graphical representation of all the firewalls 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 the path of any traffic or to find out the existence of a rule with the addition of service field. Similar to 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:

4.2.4        Usage Analysis #

For permissive rules and for regular rules to see what IP addresses or objects are actually using the specific rule, usage analysis is used. For this mechanism to work the related rules must be chosen to monitor on Rule&Object Usage menu. Once the rules are chosen and monitoring duration is identified traffic logs start to be collected by collector and when the duration ends usage analysis will be given by the system. There are two different usage analysis methods that can be used; rule usage and object usage.*

Rule Usage: This mechanism will be used for permissive rules. The system will work on the rules to find out which IP addresses are using the rule and made an analysis based on risk score to be chosen. For higher risk levels IP addresses are to be summarized to lower the total number of rules that needs to be created. For lower levels the number of rules will be higher.

Object Usage: This is a mechanism to find out which objects are actually using the rules and which are not necessary. The system will supply object usage value in percentage. Using this information rule will be edited. 

WARNING

Opinnate collector must be installed beforehnand to make usage analysis.

4.2.4.1       Rule&Object Usage #

Using this menu rules to be monitored are chosen in three steps. First devices need to be chosen. Afterwards the related rules be chosen in step 2. Finally duration period for monitoring will be identified for monitoring process to start. Started monitoring tasks will be seen on Usage Task List menu.

4.2.4.2       Usage Task List #

Tasks will be listed here with their status. Tasks for which monitoring is going on be listed as Running. Once a task is finished it will be listed as Completed. For completed tasks the rules will be shown once the risk level is chosen for rule usage analysis. For object usage the usage values be listed in percentage for each object existing in the rule.

4.2.5        Reporting #

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

4.2.5.1       New Reports #

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

CBDDO: The report for CBDDO 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.

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.

4.3         Optimization Features #

In the optimization panel 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.

4.3.1        Disable Shadowed Rule #

Shadowed rules are the rules that are not processed because there is another rule above these rules in the policy table. Since these rules are not processed, they must be cleared, however in case of any problem these rules first 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 the shadowed rule is shown with a box on the left hand side of it to choose it for optimization. Shadowing rule can also be seen when clicking on MASTER button. When clicked on it as seen in the following image the shadowing rule is shown.

With the chosen rules when clicking on the DISABLE button the optimization process be started and the workflow be seen on the task list.

4.3.2        Disable Expired Rule #

Expired rules are the rules that are non-functional since the validity time 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 chosen from the list, first screen be seen is the firewall list containing all the firewalls within environment. First, the firewalls to work on must be chosen from this list and also the reason of 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 is expired 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 be seen in the task list.

4.3.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. Last hit value on the related rule be 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 be seen in the task list

4.3.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 with this system in place  the first action to be done for optimization purposes must be this workflow since other workflows will generate new disabled rules afterwards.

The first screen 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 be clicked next screen will be the rule list that are disabled. Rule be seen like following:

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

4.3.5        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 used by other servers after a while. Therefore, the decommissioned server IP address must be cleared from the firewalls immediately. This process be automated with this workflow.

When this workflow is chosen the first thing to be done will writing 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 there will be a screen the alternatives for this decommission action. 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.

4.4         Automation Features #

In this panel standard rule creation, IP access cloning and group-based firewall policy creation processes be identified and configured. And, corporate security policy matrix be created as a table and used for approval process automation. Detailed information about each menu will be detailed here.

4.4.1        Add New Rule #

Creating manual policy change request action be started in this menu. Any admin user created on the system can access to this menu, so 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 last step meaning the path analysis and final control be handled by firewall admin user if everything is ok.

4.4.1.1       Identification #

For the identification of the request there are several fields that are also be needed for rule creation on the firewall. 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.

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.

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.

Once all the information 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 be initiated, and it will start be seen in the task list.

4.4.1.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

Schedule: Requested validity period

Service: Requested service port

Status: If the security policy is parallel to the request, then it says Allow, not parallel then it says Deny, no matching then it says None.

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 a 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.

4.4.1.3       Path 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:

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 be 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 on 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.

4.4.2        Server Cloning #

When the destination and the service information somehow does not known by the requester they may need to copy firewall policies belonging to some other server. This feature is for this need and to make a new workflow Server Cloning menu be used. This 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.

4.4.2.1       Identification #

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

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

Reference IP: The cloned IP address already active in the environment. All the policies using this IP address 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 be created.

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

4.4.2.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 Allow, not parallel then it says Deny, no matching then it says None.

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 a 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.

4.4.2.3       Path 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 be 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 on 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.

4.4.3        Group-based Rules #

Group-based rules are needed in corporations since there are groups of servers that have the same function, so have same firewall rules. Since they must have same firewall access policies, when a new server is added to this group the firewall policy creation must be easily handled and it must be a smooth process. Group-based firewall policy creation make this a smooth and automatic process. Group-based firewall automation similar to the other automations is a 3-step automation process that includes approval and analysis. Compared to the other methods groups must be created first to make this automation possible.

4.4.3.1       Groups #

Groups will be created on this menu. To create a new group Add New Group button on the upper right corner be used. Following fields exist for the creation of new group.

Group Name: A name must be given to the group to easily understand what it is, or its members are.

Description: Additional information to be given. Not a compulsory field.

New IP: The IP address the member has. With the usage of the ADD button the IP address be added to the group. And there can be any number of IP addresses within group.

When groups are added to system and there are rules created on the firewall using these groups the places where these groups are used be found using the button “Where Used”. As can be seen in the flowing picture.

The groups may also be edited or removed on this page using the related buttons as seen on the picture.

4.4.3.2       Add IP to Group #

When a group is created with a set of IP addresses it will be an easy task to add additional IP addresses to this group via this section. It will also be the mechanism used for cloning firewall policies for group-based servers by adding new IP address to this group that is already created on the system. Like other automation tasks this will also be a 3-step process containing these fields. Approval and Result pages will be like adding Group-based rules.

Select Group: This will be the group that will be used for addition of the new IP address.

Reason: The reason for this addition. Will be used for approval.

Ip address: The new IP address that will be added by entering or clicking on the + button.

4.4.3.3       Add new Group-based Rule #

Creating manual group-based policy change request action be started in this menu. Any admin user created on the system can access to this menu, so create a new group-based 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 last step meaning the path analysis and final control be handled by firewall admin user if everything is ok.

4.4.3.3.1      Identification #

For the identification of the request there are several fields that are also be needed for rule creation on the firewall. 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.

Source group: Source group name that was created on the system before.

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.

Destination group: Destination group name that was created on the system before.

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.

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.

Once all the information 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 be initiated, and it will start be seen in the task list.

4.4.3.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, 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 Allow, not parallel then it says Deny, no matching then it says None.

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 a 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.

4.4.3.3.3      Path 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.

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 on 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.

4.4.3.4       Group-based Rule Viewer #

Group-based rule viewer is the part of the system where detailed search on all the rules existing on the firewalls be made. After adding new group-based rules to the firewalls, the policies start to be seen from here.

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

4.4.4        Add New Rule Path Free #

Creating manual policy change request without path analysis be started in this menu. Firewall admin user created on the system can access to this menu and create a new rule request. Add New Rule Path Free 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 last step meaning the path analysis is a manual process decided by firewall admin and once finished the process be started.

4.4.4.1       Identification #

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

Source IP:

Destination IP:

Domain:

Username:

Schedule:

Reason

Select Protocol:

Service Port:

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

4.4.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. 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:

DestEnv:

Source:

Destination:

Schedule:

Service:

Status:

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 a 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.

4.4.4.3       Path Analysis #

This time path analysis is not made since the firewalls on which the rules to be implemented be chosen from the list. It is a manual path analysis process. 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.

4.4.5        Corporate Policy #

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

4.4.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. 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

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

4.4.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 similar to 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 on certain ports “i” icon be used. To see the details of this information settings button is to be used.

4.5         Task List #

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

ID: The internal ticket number

Ticket ID: The external ticket number coming from 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 waited for the action.

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

Action Needed: If there is a problem during path analysis this state be used.

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

5          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 support team to make further analysis debug file will be needed. Debug file can be generated from the global settings menu.

6          Glossary #

Firewall

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

Policy Analysis

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

Global Area

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

Virtual Area

Virtualization is used for isolation purposes.

Multitenancy

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

Authorization

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

Audit

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

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.

Super-user

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

Infosec User

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

Syslog

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

Ticket

On service desk systems each event or request also called as ticket.

Debugging

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

Dashboard

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

Switch

Is a network component used to connect endpoints.

Router

Is a network component making route analysis and forwarding decisions.

Rule

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

Corporate security policy

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

Logging

Act of sending log messages to a syslog server

Port

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

Virtual firewall

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

Vendor

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

Cluster

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

API

Refers to application programming interface and used for inter communication of systems

Routing

Forwarding traffic between different IP subnets.

LDAP

Protocol used to read directory information from the directory database.

SMTP

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

Network Topology

A topology showing connections between network end points.

Monitoring

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

Master

Refers to the shadowing rule.

Subnet

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

Protocol

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

Service Port

It is the same as port.

7          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.