PANW plunged 20%, should Check Point gloat?

Two days ago Palo Alto Networks share price has experienced a sharp fall, losing about 20% of its value in a single day, following second quarter results announcements and a warning towards the third quarter performance.

Some of my Check Point oriented friends would say reality is finally catching up with PAN, but I would not be that quick in judgement.

Being exposed to both vendors, I can say each one has its solid pros and cons, and technology competition is not only driving sales up (or down in some cases, lol) but also works for the best of information security in whole.

We all know that Wall Street indexes do not reflect directly the quality of the technology or even its market performance. It is all about making quick money, earning per share in this particular case. As FT explains, investors decided to get out of PANW because of the earning warning.

In reality we should be more interested in market share and its growth. During the last several years Check Point revenue grows organically with the market, plus or minus one percent, while its main competitors such as Fortinet and Palo Alto have double digit year to year growth numbers.

Yes, PAN growth is slowing down. It is not around 50%, as in 2015, but it is still estimated to reach more than 20% for 2017. Which is 2 or 3 times bigger than 7% to 9% growth achieved by Check Point through the last three years.

In other words, even while slowing down, Palo Alto Networks is catching up with Check Point market share.

Check Point still has a lot to do to change this tendency and start winning the market back.

Check Point breaks silence about CCSM issues

In my two previous posts I have I have shared my views about lack of continuity with CCSM certification and some other inconsistencies.

I have also reached out to Check Point Education Services for comments.  Wednesday afternoon new certification manager Jason Tugwell called me to make some comments of the situation. Following that call, hi has sent me an official response that I am happy to share with you now. This is what he has to say:


Valeri,

Thank you for speaking with me yesterday.  As a recap of our phone call, I would like to respond on behalf of Education Services to the issues we have had with the CCSM.

We agree that there are 2 primary issues:
1.       The inability to renew the CCSM since there is not a R80 CCSM currently
2.       Inconsistency of CCSM certification lengths of 2 years and 4 years

Response to #1 
·         We are aware that we have not released the R80 CCSM as intended.  As we await the official release of R80.10 we are currently working on an updated CCSE for R80.10 with a CCSM to follow.  Shortly after the release of R80.10 we will be releasing a CCSM with an update plan for the CCSM community.  In the interim, we have come up with a plan that will satisfy both the need for a quality CCSE and a way to extend the CCSM certification.  To any CCSM expired or not we have extended an offer to partner with CCSMs, via our email distribution group, to participate with the R80.10 CCSE exam question development.  This is an opportunity to contribute to the CCSE exam and extend the CCSM certification for 1 year.  We believe the CCSM community can contribute to make the exam a solid product with challenging skill.  If you are a CCSM and not part of our email distribution group, contact Jason Tugwell for more information.

Response to #2
·         We have identified that there have been the errors with CCSM certification listing two different validation dates, 2 year or 4 year.  This inconsistency is still undergoing investigation, however, it appears that it was a clerical error that has affected a small percentage of the CCSM’s.  We do apologize for the error and the confusion it has generated nevertheless, going forward all CCSM certifications will be a 2-year certification as intended.  (See the Check Point Certification FAQ: All professional certifications - those taken in a proctored exam environment - are good for, or considered “Current”, for two years.)  When the investigation is concluded, we will alert the community.

Let me express my sincere apologies for any issues this has caused and my gratitude to the network of Check Point Certified professionals that are interested in maintaining their certifications.

Regards,
Jason Tugwell “Tug” 

Thank you for your response, Jason. I will continue monitoring the situation and will share with the community any further development.

CCSM, more warning signs

In my previous post I have started to write about issues around CCSM certification with Check Point. As said there, if your CCSM certificate expires soon, you will not be able to renew it, as no new exam version is available yet.

Since then I have been approached by several people with questions and stories about their own CCSM certifications.

Surprisingly, I have realized there is a mess with CCSM certification period. While majority of CCSM professionals have got certificates valid for two years only, some others got four years of certification.
Here are some stories.

CCSM certification extended for two more years.

A colleague of mine passed CCSM exam in 2015. As soon as the qualification had appeared on his profile in UserCenter, he downloaded his e-certificate PDF. Earlier this year, when the company was updating its partner status, he checked his status, and UC said, his CCSM expires early February 2017. That statement was also backed up by e-certificate he downloaded again. Now, here is the twist: although e-cert downloaded in 2017 shows two years of CCSM, the older 2015 e-cert has four years. Most interestingly, his certificates have the same name and ID number, but different expiration dates. Later on, my colleague has raised a ticket with account management, and after sending them 2015 e-cert he has received two year extension.

2017 CCSM get four years

Someone who asked me not to reveal his name said he has been granted CCSM for four years at the beginning of 2017. Same situation is mentioned in the comments to the previous post by one of my readers as well.

Trying to get to the bottom

Being surprised by the inconsistencies, I have put my investigative blogger hat, trying get to the bottom of the truth. I have reached out to Shay Solomon, Director of Education Services at Check Point, asking for a clarification. Shay has answered that CCSM is valid for two years only. My next question was, how comes some people get four year of certification.

Then something strange happen. Shay has asked me to provide the names of my sources. I have made several attempts to get more specific information and then even acknowledgement of the problem's existence and Check Point plans to fix it. Instead, all I have got was "We will look into in".

So here it is, folks. Check Point not only fails to provide means to maintain CCSM status without interruption, but also cannot decide if it is valid for two or four years. The Director of Education Services says two years, but people get certificates for four.

At this point I do not know the gravity of the situation. To assess it, please let me know if your current CCSM has two or four years. Please check both your e-cert you have downloaded and UserCenter status, as they can show different things.

As the issue might be quite delicate, please do not use your real name in the comments or, alternatively, just send the info to my private email address: "varera (at) gmail dot com".

Most importantly, if your e-cert shows four years, keep it in a safe place. You may have to appeal later, if CP takes some sort of a corrective action.

I will continue writing the story as it develops.

CCSM lacks continuity, and it is Check Point's fault

Security Master program (CCSM) is the highest certification with Check Point available today. It was introduced at the end of 2014 to replaces failing CCMA certification.

It is clear now that CCSM is also experiencing some road bumps on its way.

During the last two weeks I have received several reports from CCSM professionals about inability to extend their CCSM status.

The issue is, CCSM certification is valid for two years only. Just to remind you, CCMA privileges had four year. Many people who jumped into CCSM at the beginning of 2015 are now facing the fact their certification is about to expire. Yet, there is no way to extend it.

Yes, that is not a mistake. You cannot extend your current CCSM certification. The usual was would be to take a new CCSM exam. But here's the caveat, it is still the same CCSM exam based on R77 version. And, not surprisingly, you cannot retake the same exam twice, if you passed it the last time.

One could extent one's CCSE for a year by taking two blade exams, but there is no such an option for CCSM. Nothing can be done. You may only wait till the next version based on R80 will be out.

I have asked Check Point Educational Services to comment on this situation. This is what they say:

"CCSM certification cannot be extended until the R80.10 software, certification training course, and certification exam is released.  This is a known issue."

I personally find the situation quite unsettling. I am privileged to know personally many of Check Point Education Services team members; and trust me, those people are dedicated, intelligent and hardworking.

Why are the processes failing then? Is it something about the system itself? I can't say. Yet I find necessary to start a dialog and to discuss openly and freely good and bad of being a Check Point certified professional.

Please do not hesitate to share your opinion too.

I will continue writing about history, issues and wins of Check Point certification system in this blog. Stay tuned.

Using "fw monitor" command is even easier than you think

Arguably, fw monitor is one the most important troubleshooting tools with Check Point firewalls. It is flexible, extremely powerful and versatile. It is also one of the most frequently misused tools. There is a single compelling reason for both cases.

fw monitor uses INSPECT, an internal C-like language that is used by Check Point to build kernel-based security. Same language is used to define any object, action, protocol and even IPS protections. It is also a huge piece of knowledge that Check Point never shared in full.

Here is a conundrum. You can write extremely complex and very effective filter with fw monitor. The only condition is, you need to possess an intimate knowledge of INSPECT. In other words, to do so, you have to be a Check Point developer.

There are some documents and references about fw monitor usage. There is a well known long-read from 2003, for example. The doc is compelling, very details and yet mostly useless on the field. Who would use IP header offset to filter traffic, really? I have never done that in more than 17 years of working with CP FWs.

There is also a fantastically well written SK30583. It has quite nice set of examples, large list of filtering options and a very elaborate syntax explanation.

However, there is something even better. Imagine you are stuck in a datacenter dungeon, no internet access and some pressing matter to resolve. Where can you find a good reference to fw monitor syntax and options, if SecureKnowledge is not available, and your personal notes are at the office on your desk?

Well, you do not have to pull your hair out. You are working with Check Point FWs, remember? Just get on CLI and look into $FWDIR/lib/fwmonitor.def on one of the firewalls.

The file has a list of all fw monitor macroses you can use.

For example, remember my line from the previous post about kernel debug filter? Here it is:

fw ctl debug -e "accept host(8.8.8.8);" 

I use here host macros that automatically generates filter for source and destination IP addresses.

Now, this is how this macros is described in fwmonitor.def file:

#define host(_addr) (ip_src=(_addr) or ip_dst=(_addr))

Also, remember how annoying it is when your own SSH session is creeping into fw monitor output when you are trying to run a trace? Here is a no_term macros:

#define no_term ((not ssh) and (not telnet)) /* remote terminal */

And just in case you ever forget the rest of traffic filtering syntax, you can always look into $FWDIR/lib/tcpip.def file for reference.


The author thanks Sergei Shir, Check Point SecureKnowledge content developer, for his dedicated work and references provided in the comments to the previous post in this blog.

New certification manager at Check Point Education Services

Everybody, meet Jason "Tug" Tugwell, new Check Point Certification manager.

Jason is the new face in Education Services, but not at Check Point. He joined Check Point in 2007 as a tech advisor and then was leading different TAC teams at Dallas, helping out customers.

I am sure, he will make a difference in Check Point certification process.

Personally, I am looking forward to see more refined technical real world inspired question in the new certification exams.

All the best from here. Tug us well, mister Tugwell.

Kernel debug filter that is almost never used

Some of us are running kernel debug on Check Point FWs from time to time, especially students of my Advanced Check Point Troubleshooting Course.

There are many tricks and best practices, but one that I love the best is applying INSPECT traffic filter on the output. And guess what, this one is rarely used.

The issue is simple. When running FW kernel debug, we are trying to extract as much debug information as possible. Usually Check Point support engineers ask customers to run something like "fw ctl debug all". I assume they find filtering out gigs of text files very rewarding.

On my side, I am trying to keep things simple and controllable, hence enabling only necessary debug flag. Yet, by default you get all kernel output for all packets traversing your FW during the debug session, and that might be still too much when trying to debug a single faulty connection.

This is how "fw ctl debug" help output looks like in practice:

Usage: 
fw ctl debug [-d ] [-s ""] [-v (""|all)] [-k] [-x] [-m ] [-e expr |-i | -u] [+|-]

I have highlighted there the interesting part. If you ever used fw monitor, you know -e flag already. It stands for expression, a traffic filter based on INSPECT syntax.

Same deal here. You can actually limit quite a lot of unnecessary debug printout by filtering only the messages related to some particular traffic.

For example, adding
fw ctl debug -e "accept host(8.8.8.8);" 
to your kernel debug commands you will get output related to traffic to and from the famous Google DNS server.

This saves lots of time and effort when analysing the debug info afterwards. As all the other parameters, this filter is reset with fw ctl debug 0.

Have fun.