Basics

Using Tufin SecureChange, there are some options for Decommission. Sometimes it is not clear, what is meant by the different workflow types. So here you find a brief description.

 

Access Request

When having an Access Request Workflow, new access "from - to" can be requested if the action is "accept".
Using the other option "remove" allows to decommission access "from - to".

In the example shown above, the access from 10.1.1.0/24 to 10.2.2.0/24 using the protocol https is no more needed. Because it is an Access Request ticket, many IP addresses can be used here. Besides this, more than one Access Request can be defined within one ticket. The requester does not need to care which firewalls are involved and which firewall rules are affected. So the removal of "access" might affect many firewalls and rules, respectively.

 

Rule Decommission

A ticket for a Rule Decommission Workflow always starts in Tufin SecureTrack, not in SecureChange. The ticket is opened for a specific rule configured on one firewall device. This must not be mixed up with an Access Request.
Please consider the configuration requirements, e.g. the SecureTrack user needs to be authorized to open such a ticket in SecureChange.
First, the rule is selected in the Rule Viewer.

Clicking on the button on the right side opens a menu where the option "Decommission rule" can be selected. The next step is to provide a subject for a ticket and select the workflow. Now, a new ticket is created in SecureChange, allowing to check and submit the request.

 

 Decommission of network objects

A third option for decommissioning is the use of a Decommission network object Workflow. This kind of workflow is used to remove network objects from rules and groups. So after having the ticket closed, the selected object is no more in use.
Hint: If an object that shall be removed is "last in cell", SecureChange Designer recommends removing the whole rule. This is because if the "last in cell" object is removed, the usual firewall configuration replaces the lost object with "any" by default.

The network, server, or address range needs to be provided manually.
Please regard that the object is not removed from the Firewall Management. It's still there, but unused.

 

 

 

Many thanks to Tufin for awarding AERAsec at the EMEA Partner Summit as

    Best Support Partner 2021 in Central EMEA

After 15 years of successful cooperation, we are proud to get this award, together with warm words from Pierre Visel (Vice President Central and Eastern Europe).

 

 

 

 

 

Tufin Best Support Partner 2021 in Central EMEA
Tufin Best Support Partner 2021 in Central EMEA

After the first vulnerability in Apache Log4j has been found and is discussed on the Internet, some more have been identified. All together, until now three vulnerabilities have been found. They are described in CVE-2021-44288 (resolved in Log4j 2.15), CVE-2021-45046 (resolved in Log4j 2.16), and CVE-2021-45105 (resolved in Log4j 2.17).

Tufin has checked whether Tufin Orchestration Suite is vulnerable or not.
The latest status can be found here: https://forum.tufin.com/support/kc/latest/Content/Suite/CVE-2021-44228.htm?cshid=CVE-2021-44228.
Some official patches are available, i.e. for RTOS 19.3 and above. If you are currently using R19-2 or earlier, please upgrade to a supported version of TOS.

It is recommended to check the latest status (Tufin Portal > Security Advisories) and to subscribe to Tufin's mailing list.
Please check also the Tufin Portal also for additional information.

 

 

 

 

 

In SecureTrack it's possible to mark rules as "legacy" or "stealth" in the Rule Metadata shown in the Policy Browser. Marking a rule is also relevant for decisions and/or results of the Designer and Verifier in SecureChange.
To mark a rule, SecureTrack needs to be opened. Then go to Menu > Home > Policy Browser and select a device. After this, mark the rule that shall become a "legacy rule" or a "stealth rule".

The selected rule is shown with a yellow background afterwards. At the top right, a pen is shown. A click on this pen opens a window that allows to edit the metadata of this rule.

In this window, under "advanced options" the rule can be marked as "legacy" (rule action: accept) or "stealth" rule (rule action: drop/deny). To put this information into the rule metadata, "save" needs to be clicked at the bottom of the window.
These are the consequences:

Legacy Rule

In most cases, a rule accepting traffic is marked as "legacy" when it's too open, e.g. allowing every service. In a SecureChange Access Request, the Designer finds usually out that the traffic using even an exotic protocol is allowed due to this rule. If it's marked as "legacy" rule, it's treated as shadowed rule and the Designer puts a new rule above the marked rule. The Verifier of SecureChange also ignores the rule marked as "legacy" rule, i.e. even if every service is allowed it will state that it's not because this rule is ignored from the Verifier. 

Stealth Rule

A rule denying traffic marked as stealth rule is usually protecting a firewall gateway because every access from anywhere to this gateway is forbidden by this rule. Each allowed traffic destined to the gateway itself needs to be placed above the stealth rule. The stealth rule usually is located in the top part of a rule base.

 

Consequences for SecureChange Designer

The Designer considers this kind of rating a rule. If a rule marked as "legacy" would match the traffic, the Designer must not consider this rule for traffic, so above the "legacy" rule a new rule is suggested. This behavior is correct, even if the requested traffic is allowed by the other rule.

If a rule is marked as "stealth" rule, all suggested new rules for accepting traffic are located below it.

 

Possible problem

If rules marked as "legacy" and "stealth" in a rule base, a problem might occur if a rule marked as "stealth" is below a rule marked as "legacy". An example would be rule 6 as a "legacy" rule and rule 25 as a "stealth" rule. In this case the Designer of SecureChange states

"No suggestion available: Cannot determine correct location for a new rule when the requested traffic intersects a legacy rule which is included in the stealth section"

 If you get this error message, keep an extra eye on "legacy" and "stealth" rules...

 

 

 

 

 

Many thanks to Tufin for nominating us at Tufinnovate EMEA 2019 in Lisbon. We are proud to be awarded to be

  2018 EMEA Service Provider of the Year

So about one year after becoming the first Tufin Service Delivery Partner in Central Europe, it's an honor for us to be awarded with this price.

Award Ceremony Tufinnovate 2019, Lisbon - Portugal, 11.09.2019
From left to right:
- Ruvi Kitov, CEO and Co-Founder Tufin Technologies
- Kevin Raff, IT Security Consultant AERAsec
- Dr. Matthias Leu, CEO and Founder AERAsec
- Mike Menegay, VP of Global Channels Tufin Technologies
- Remko Postma, Director of Channels EMEA Tufin Technologies

 

 

 

Page 2 of 3