Vote for R77.30 support extension

[Danny]

Check Point R77.30 support expiration is near.

Regarding Check Point's Support Life Cycle Policy it will expire in September 2019!

While R80.20 is now Check Point's default recommendation and runs quite stable already, it doesn't feature all functions R77.30 has and is still being heavily developed. End users and partners are desperately waiting for newer releases, such as R80.20 GA for gateways and the first hotfixes in order to adopt to it after thorough planning, preparation and testing. This takes time while the support end for R77.30 is very close.

R77.30 on the other hand is proven to run stable, is well patched, latest jumbo hotfixes often just refer to rare scenarios. End users know how to manage it and need time to adopt to the all new R80 workflow. They use tools like SmartWorkflow that they need to completely rethink after migrating to R80. Even simple tasks, such as searching for objects with duplicate IP addresses, which were just a click away in SmartDashboard R77.30 now require to install and run python scripts in R80. Many additional topics could be easily mentioned here that will surely be cool with R80.x in the future but are currently still under development.

Do you think Check Point should publicly extend R77.30 support, at least for another year?

Extend R77.30 support!	357
Let it expire in September 2019!	71

[Vincent_Bacher]

I cannot confirm that R80.10 is not stable in principle. 

The only unstable Installations I faced yet are a vsx cluster but IA portal only and some CPU and/or ram issues at a high frequented sms but just sporadically.

So I did not see instability in general, yet.

[Tomer_Sole]

@ revert: see this thread Dynamic revisions in R80.x SmartConsole - our current recommendation is to use the Gateway-level revert using Policy Installation History. It reverts everything, not just rules.

We do have plans to increase the core capability of the dynamic revisions in our next releases.  However, I want to make the argument that Gateway-level revert is useful for disaster recovery.

I want to give some examples for features towards MSSP’s that are available in R80.20. There are more. 

• Multiple Sessions Per User: The same person can work on multiple tickets without affecting his/her other tickets. also available: making private changes and installing the policy of the public changes.
• You can schedule your policy installations from the GUI (multi-domain users)
• REST API. Running remote calls to export, import, fetch and integrate with 3rd party is better than bash on the server. REST is an industry standard and it enables new customers to use Check Point in ways that they’re used to with their other products. There is now REST API for Diff Changes, where-used, policy match search and more.
• MDS-level real-time SmartView is unparallel in the industry for monitoring security events.
• Better HA

[Tomer_Sole]

@domain migration tools: We are aware of this limitation. This did not make the newly-released R80.20. However I want to point out that we have plans to introduce these tools in our next releases.

[Douglas_Rich]

We're stuck at R77.30 until these tools are delivered, meanwhile the clock is ticking down quickly for the R77.30 EOL date.  This is causing a severe business disruption for MSPs!

[S_E_]

Exactly.

Removing features in R80 and then telling R77.30 is EOL does not work.

This breaks business and trust.

[Thomas_Hecht]

Hi,

the R77.30 support seems to be extended.

/thomas 

[Danny]

Thanks Check Point for listening to your community and customer requirements.

[Uwe_Knoetsch]

Thanks Danny for start this Diskussion.

[PhoneBoy]

I have not seen any official communications about this yet, but this looks promising.

Benny Shlesinger‌ anything we can share?

[Thomas_Hecht]

Hi Dameon,

.. i hope you remember me

/thomas

[Benny_Shlesinge]

Indeed R77.30 was extended until September this year, to allow some more time for upgrades.

So, yes - CheckMates do make a difference!

We also added R80.20 to the support lifecycle page as a major version, which means it will be supported until September 2022.

There was never a batter time to plan ahead your upgrades to R80.20...

Benny.

[Douglas_Rich]

4 month extension still isn't enough given there isn't a version or R80.xx released yet that any MSP can support for Multi-Domain.    Should be 12 months after a viable product is released GA for Multi-Domain!

[_Val_]

yes he does 🙂

[_Val_]

What do you miss on MDS part with R80.X?

[Ryan_St__Germai]

The only reason we would want an extension of R77.30 is due to a FIPS 140-2 requirement. Our gateway must be certified in order to interconnect with a customer endpoint. Any news on whether R80.20 will be FIPS 140-2 certified?

[Douglas_Rich]

1. All Customers are in a single Database, no more clear separation of data.

2. You can't backup Customers CMA Databases individually.

3. You can't migrate the Customers CMA to another MDS.

4. You can't migrate the Customers CMA to a Smart Center Server.

5. You can't onboard/migrate any Customer who has already upgraded to R80.xx to an R80.xx MDS.

So to support an R80.xx MDS you need to tell your customers you can't backup there Managers data in a usable medium. Once you are at R80.xx you can't manage any new customers who have already upgraded. And if a customer wants to end their MSP contract they can't take their configuration with them.

[Malcolm_Levy]

We should hopefully have a new FIPS 140-2 certificate within 6 months. We completed lab work and the lab report is being finalized. We have a FIPS 140-2 draft security policy that I can share. The main time factor is the NIST-CMVP queue and feedback that we may need to address from the assigned Validator. After the lab submits their report we will be listed in the Modules In Process link found on the right have side of this page Modules In Process List - Cryptographic Module Validation Program | CSRC  : 

We are certifying the Check Point Cryptographic Library of R80.20 through FIPS 140-2 on two operational environments:

- Check Point GAiA Operating System at version R80.20 on VMware ESXi 6.0.0 running on a Dell PowerEdge R610 server

- Check Point 12400 appliance with Check Point GAiA Operating System at version R80.20

We will be awarded a new certificate.

The existing certificate is evaluated on

- Check Point 12400 appliance with Check Point GAiA Operating System at version R77.30 (see certificate # 2995 on Search - Cryptographic Module Validation Program | CSRC  

Note that according FIPS Implementation Guidance IG G.5 Check Point  can affirm the certificate validation of the Check Point Cryptographic Library for other General Purpose Computers (GPC), such as enterprise and data center appliances and SMART-1 because:

The certificate is for a firmware module

According to FIPS Implementation Guidance:

1. A vendor may perform post-validation recompilations of a software or firmware module and affirm the modules continued validation compliance provided the following is maintained
2. Firmware modules (i.e. Operational Environment is not applicable) that do not require any source code modifications (e.g., changes, additions, or deletions of code) to be recompiled and its identified unchanged tested operating system (i.e. same version or revision number) may be ported together from one GPC or platform to another GPC or platform while maintaining the module’s validation

[_Val_]

Thanks, this is very informative. Tomer Sole‌, could you please comment?

[Tomer_Sole]

@domain migration tools: We are aware of this limitation. This feature did not make the newly-released R80.20. However I want to point out that we have plans to introduce these tools in our next releases.

[Ryan_St__Germai]

Thank you very much for the detailed response. What factors contribute to what version CheckPoint chooses to get certified? As you mentioned R77.30 is the current certified version. What made CheckPoint not certify 80.10 or 80? Simply because they were not as complete as 80.20?

[PhoneBoy]

While I don't have intimate knowledge of the certification process, I do know it's a lengthy process.

This plus commercial realities makes the "target of evaluation" somewhat of a moving target

My guess (and it's only that) is that we started the process with R80.10, but moved to R80.20 once that was GA.

The logic being: it's the version with the longest useful lifespan by the time the certification is expected to be granted.

[Malcolm_Levy]

We should hopefully have a new FIPS 140-2 certificate within 6 months. We completed lab work and the lab report is being finalized. We have a FIPS 140-2 draft security policy that I can share. The main time factor is the NIST-CMVP queue and feedback that we may need to address from the assigned Validator. After the lab submits their report we will be listed in the Modules In Process link found on the right have side of this page Modules In Process List - Cryptographic Module Validation Program | CSRC  : 

We are certifying the Check Point Cryptographic Library of R80.20 through FIPS 140-2 on two operational environments:

- Check Point GAiA Operating System at version R80.20 on VMware ESXi 6.0.0 running on a Dell PowerEdge R610 server

- Check Point 12400 appliance with Check Point GAiA Operating System at version R80.20

We will be awarded a new certificate.

The existing certificate is evaluated on

- Check Point 12400 appliance with Check Point GAiA Operating System at version R77.30 (see certificate # 2995 on Search - Cryptographic Module Validation Program | CSRC  

Note that according FIPS Implementation Guidance IG G.5 Check Point  can affirm the certificate validation of the Check Point Cryptographic Library for other General Purpose Computers (GPC), such as enterprise and data center appliances and SMART-1 because:

The certificate is for a firmware module

According to FIPS Implementation Guidance:

1. A vendor may perform post-validation recompilations of a software or firmware module and affirm the modules continued validation compliance provided the following is maintained
2. Firmware modules (i.e. Operational Environment is not applicable) that do not require any source code modifications (e.g., changes, additions, or deletions of code) to be recompiled and its identified unchanged tested operating system (i.e. same version or revision number) may be ported together from one GPC or platform to another GPC or platform while maintaining the module’s validation

[Malcolm_Levy]

We always try to certify the latest version, and often migrate across versions whilst in process. 

We also consider cross dependencies between certifications as often certifications build upon each other, and customers need multiple certifications that are aligned.

For this reason we are focusing on R80.20 for FIPS 140-2, NIAP-CCEVS cPP based Common Criteria, IPv6 to USGv6 profile, DISA-DoDIN, and NSA-CSFC.

[Divine_Ambe]

I believe R80.10 and now R80.20 embodies everything we need to advanced. But i think in a country like mine which we're still trying to get pple understand R77.30 and Gaia or CP itself lets give chance to everyone an push them to move fast an quick 

[Aloke_Paul]

It is good new that support extended for R77.30.....Cool

[Dawei_Ye]

I would like upgraded my customers' Check Point devices to R80.10 as far as I can.and I really did it for the last year.

R80.10 is more efficient and api really did me a big favor.

But only one blade work not stable in my situation:Application control and URL Filtering.

I have 2-3 customers meet the mismatch of the rules of appc and urlf.

They are cannot match a pre-defined categorization or a custom-defined URL(even the domain object) and some other wired things.

Ordered layer and inline layer are all included.Local appliances and vSEC gateways are included.

With the local Check Point SE help,we have discussed these issues with R&D team,and they are trying to make a hotfix to fix these but I still didn't get the hotfix.

But it seems not everyone run into these issues .I didn't see anybody post this question in community.

btw,sorry for my poor English:)

[PhoneBoy]

If you want to get community advice on this, I'd start a separate thread with more details.

[Danny_Yang]

Hi Dawei,

Could you please provide the SR number you've created for this issue?

We can help to follow-up your requirement.

Cheers,

Danny Yang

[Jim_Ribeiro]

Concerned about deployed appliances not able to run R80.10.

[S__Andrae]

Danny Jung are there any news about EOS of r77.30?

We're thinking about chaning to another NG firewall solution, because we don't want to pay for training and migration while not having meaningful advantages for our use cases. Maybe check point has just become to big for our size of company.

Regards!