www.tufin.club
Tufin Orchestration Suite 16-1
- Details
- Category: Version update
Parallel to the Check Point CPX in Nice, Tufin has released version 16-1 GA. Until now, the first HF is available, too.
Please find some information about changes in this version below.
This version includes some improvements, e.g.:
- New Cloud Features for AWS, e.g. automated Connectivity Modeling for AWS Applications, policy based analysis of connections, connection discovery of applications and much more
- New Cloud Features for NSX, e.g. NSX Application Map
Changes regarding SecureTrack:
- PaloAlto:
Support of Palo Alto rule tags, security profiles and log profiles - Fortinet NAT:
Support vo VIP, IP Pool and Destination Interface NAT as far as the Gateway is managed by FortiManager - Check Point:
Full Support of Check Point R77.30 Management - Cisco:
Support of ASA 9.5 - Upgrade of HTTPD and JMS Server from TLSv1 to TLSv1.2
- Improvements regarding the Unified Security Policy (USP). Further requirements can be added now, e.g. Logging required, no ANY as Source, Destination, Service, etc.
- In Rule Base Optimization now a rule can be marked as "legacy". If SecureChange would recommend a change to this rule, it's ignored and a new rule will be defined. This is for optmization of "old and complex" rule bases.
- Improvements of the REST API, esp. regarding Authorization and Compare of rule bases.
Changes regarding SecureChange:
- The Designer has been improved, esp. when there are more than one Access Request in a ticket.
- Visual presentation of rules in the Designer
- The REST API now offers options for "Modify Group", exclusion of Devices and more. Please find an extended online documetation of the REST API in SecureChange now.
- Import of Access Requests is now possible for "Comment" and "Action" also
Changes regarding SecureApp:
- Introduction of a Connectivity Map for a graphical view of all connections affecting an application, regardless of involved devices.
- Improved support of AWS applications
- Improvements of the REST API, esp. for AWS
Further improvements and corrections are included.
The latest version of the Tufin Orchestration Suite can be found at the Tufin Portal: https://portal.tufin.com
Communication between SecureTrack and SecureChange
- Details
- Category: SecureChange
If there is a distributed installation with a SecureTrack Server and a SecureChange Server, communication is needed between these two servers.
Necessary communication: HTTPS (443/tcp) in both directions.
SecureChange Server needs information from SecureTrack, e.g. about Topology and Rule Bases of the firewalls. The SecureChange Designer needs also the opposite direction connecting from the SecureTrack Server to the SecureChange Server. If this doesn't work, the designer will result in an error.
To configure the SecureTrack Server in SecureChange, go to Menu > Settings > SecureTrack
To configure the name of the SecureChange Server used e.g. in E-Mails, select Menu > Settings > Miscellaneous
The name or IP address listed here represents the SecureChange Server and will also be used for the communication between SecureTrack and SecureChange. If a wrong name or IP address is configured here, SecureTrack won't be able to communicate with SecureChange since only this name/address will be contacted from SecureTrack.
For sure, the name needs to be resolvable for users too, since they will find this name in their E-Mail regarding e.g. a new task.
Check Point Management - No Topology (?)
- Details
- Category: SecureTrack
When connecting a Check Point Security Management Server to SecureTrack, there are two possibilities to gather the topology:
Check Point Security Management Server only
In this case, Secure Internal Communication is set up to have a secure connection between the SecureTrack Server and the Check Point Management.
The Topology for SecureTrack is read from the Interface information defined in the Check Point Firewall and Cluster, respectively. Anti-Spoofing information is also read to get as much information as possible about the Topology.
Check Point OS Monitoring
In this case, the Topology is read from the monitored devices directly using SNMP. Other information isn't gathered - information from the object defined in the Security Mangagement Server is ignored.
Lesson learned:
If Check Point OS monitoring is activated and the SecureTrack Server has no possibility to read information using SNMP (161/udp), no information about the Topology is imported and therefore this device isn't shown in the SecureTrack Topology. Allowing SNMPv3 between the SecureTrack Server and the firewall device helps to avoit this potential problem.
glibc vulnerability in TufinOS 2.x
- Details
- Category: TufinOS
Please update your TufinOS
Google Security has found a vulnerability in glibc, a commonly used library:
https://googleonlinesecurity.blogspot.co.il/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
A remote attacker could create a specially crafted DNS response which could cause libresolv to crash or, potentially, execute code with the permissions of the user running the library.
Tufin points out, that a patch is needed for TufinOS 2.10:
- TufinOS 1.x isn't vulnerable
- TufinOS 2.x is vulnerablle
Tufin has published a patch for TufinOS 2.10:
https://portal.tufin.com/Doc/Default.aspx?id=1169
Please install this patch. If necessary, carry out an update before so the patch can be installed.
Generic Device
- Details
- Category: SecureTrack
Tufin SecureTrack offers some possibilities if a device can't be monitored directly. One of them is to define a Generic Device. Just a short explanation of this kind device and how to configure it.
Generic Device
This kind of device is defined for SecureTrack Topology only. No Monitoring, no security configuration and no logs are imported into SecureTrack. Such a device is necessary if a non monitored device is needed to correct / enhance the Network Topolgy SecureTrack is working with. As you know, that's the base for enhanced features of SecureChange and SecureApp. So it's important to let the Topology of SecureTrack show the reality regarding Networks and Routing.
Since no data is used for reports, analysis of rule bases etc. no license for such a device is necessary.
Why and how to define it? Let's assume you have a topology which isn't according with the reality. Mostly the reason is a missing device, connecting two or more networks. The topology shows like e.g.
So defining a Generic Device might help to improve the topology to show the reality.
Just create a plain ASCII file with all relevant data. Referring to the User Guide might be useful... ;)
If you want to define a Generic Device to connect the device "firstvs" managed by "SMC-Rio" with the net 198.18.50.0/24 the plain ASCII file might look like this example:
Name, Ip, Mask, Vrf
interface1, 192.168.50.254, 255.255.255.0
interface2, 172.16.41.254, 255.255.255.0
Destination, Mask, Interface, Next-Hop, Vrf
0.0.0.0, 0.0.0.0, interface1, 198.18.50.1
Now it's time to import the file to SecureTrack. This is done in the menu option "Network > Topology > Add Generic Device".
The next step is to save the file and to wait for a moment. SecureTrack is calculating the new Topology. After finishing it, the Generic Device is shown in the SecureTrack Topology. For sure, this change will also be known in SecureChange.
So from now on, this device is known in Tufin SecureTrack Topology and also considered by the other components of the Tufin Orchestration Suite.
If there is a "big Core Device" by Cisco, no definition of all Interfaces and routes is necessary. Just an import of exported configuration data does the job. Redirect the output of
# show ip route
# show ip interface
to a file and import it as shown above. We have proved this also for very big configuration files - and it works if it's a Cisco device...
Welcome
- Details
- Category: Admin Management
Welcome to blog.tufin.club
We are glad that you found this blog about solutions by Tufin Technologies. Their product is the Tufin Orchestration Suite which consists currently of the parts SecureTrack, SecureChange, and SecureApp.
This blog is operated by AERAsec Network Services and Security GmbH in Hohenbrunn/Germany. AERAsec is Gold Partner of Tufin and also selling all Tufin Solutions. Besides sales, AERAsec also delivers support for all Tufin Solutions even if direct support is provided by Tufin Technologies. Esp. german speaking customers often like first and second level support in German.
The main author of this blog is Matthias Leu. He started with Tufin products in 2006 and is the only german speaking "official" TCSE Trainer.
Please feel free to contact AERAsec by E-Mail via info at aerasec.de
Page 22 of 22