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

 

 

 

 

 

At Tufinovate 2020, AERAsec has been nominated as

EMEA SDP / Service Partner of the Year

Thanks to Tufin for this award!

 

 

 

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

 

 

 

Many installations use Tufin Appliances to run SecureTrack and/or SecureChange with SecureApp. In some situations it feels as if with each new version of TOS the performance becomes slower and slower while in parallel the load of the machine becomes higher - even if there is no change in the number of monitored devices, log volume or number of concurrent users.

Looking at older versions like e.g. 17-1, the requirements for SecureTrack and SecureChange on a machine were 4 processor cores and 4 GB RAM. Recommendation for productive environments were at least 4 processor cores and 8 to 12 GB RAM.

Since then many features have been added to Tufin Orchestration Suite, so the software package has become much bigger, e.g. 16-1 was about 750 MB, 17-1 was about 810 MB while 18-1 has grown up to approximately 1.4 GB. A possible reason are many new features that are added to the code. The size of the code has nearly doubled which in consequence leads to an increase of hardware requirements. These are today:

  • CPU: 24 Cores
  • RAM: 32 GB
  • HD: 1 TB usable space in RAID

For a production environment recommended hardware is

  • CPU: 32 Cores
  • RAM: 64 GB
  • HD: 2 TB usable space in RAID

Following these recommendations, a Tufin T-510 fulfills minimum requirements only. Even if this machine has been suitable for some environments about two or three years ago, it's currently recommended to use in productive environments the appliances T-1100 or T-1100XL only.
The load on a machine can be reduced using Tufin Distributed Architecture. In this configuration, Remote Collectors and Distribution Servers take load from the Central Server. Additional licenses are not required, only additional hardware.

The "real requirements" depend not only on the number of monitored devices, but also on the size and complexity of rule bases as well as the number of logs, concurrent users etc. Please consult your Tufin SE to get more detailed information about your individual hardware requirements.

 

 

 

 

Many thanks to Tufin Technologies for nominating us at Tufinnovate EMEA 2017:

AERAsec is Tufin "Partner of the Year 2016 Central EMEA"